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ABSTRACT 

In  1977  the  ACM  Special  Interest  Group  for  Graphics 
(SIGGRAPH)  formed  the  Graphics  Standards  Planning  Committee 
(GSPC)  to  develop  a  standard  for  the  industry.  The  result  of 
their  efforts  was  the  CORE  graphics  system.  This  study 
discusses  that  system  and  the  issues  involved  in  its 
creation.  It  describes  Bell  Northern  Researcn's  approacn  to 
implementing  CORE  with  their  Virtual  Graphics  Machine  (VGM). 
The  installation  of  7GM  at  the  Naval  Postgraduate 
School  on  a  PDP  11/50  with  the  RSX-11M  operating  system  is 
described  as  well  as  the  initial  efforts  to  expand  it  to 
drive  the  RamteK  RM-9400  Graphics  Display  System. 
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I .   IN TRODOCT ION 

Computer  graphics  is  a  relatively  young  technology  and 
is  expanding  at  an  extremely  rapid  rate.  As  a  recognized 
discipline,  it  marts  its  birtn  with  Ivan  E.  Sutherland's 
SKETCHPAD,  in  1962.  As  tne  field  has  expanded,  hardware  has 
developed  along  several  different  lines.  The  available 
devices  range  from  computer  driven  mechanical  pen  and  ink 
and  photographic  film  plotters,  to  refresh  display  devices 
where  digital  stored  images  are  repeatedly  painted  on  a 
television-lite  Cathode  Ray  Tube  (CRT).  There  are  also 
storage  tube  displays  waere  the  CRT  itself  retains  the 
image,  thereby  eliminating  the  need  for  storage  and 
continuous  refreshing.  The  latest  development  nas  been  the 
raster-scan  devices  where  a  matrix  of  intensity  values  is 
output  to  a  refresh  type  CRT. 

The  software  supporting  these  various  devices  has 
developed  along  lines  as  diverse  as  the  hardware.  Despite 
wide  variation  in  device  capabilities  there  is  a  large  body 
of  graphics  methodology  that  is  common  to  all  display 
systems.  The  existence  of  this  body  of  shared  technology 
has  contributed  significantly  to  the  movement  toward  tne 
development  of  a  software  system  that  would  be  common 
throughout  the  community  of  graphics  programmers. 


The  concept  of  a  standardized  graphics  system  is  not  a 
new  one.  The  publication  of  the  ACM-SIGGRAPH  Graphics 
Standards  Planning  Committee  (GSPC)  report  in  1977,  however, 
was  the  first  widely  accepted  effort  in  the  area  of 
standardization.  This  CORE  graphics  system  is,  as  yet,  only 
a  proposal.  CORK  is  envisioned  by  the  GSPC  to  be  a  first 
step  toward  a  true,  industry-wide  standard.  Tne  nope  for  tne 
current  CORE  system  is  that  it  will  be  implemented  at  a 
large  number  of  computer  graphics  installations  and  be 
subjected  to  a  variety  of  applications.  Such  widespread  use 
of  CORE  is  the  best  way  to  fully  challenge  the  proposed 
standard.  Extensive  use  of  the  system  will  build  a 
comprehensive  body  of  knowledge  about  it  and  should 
highlight  its  strengths  and  weaknesses.  Based  on  sucn 
experience  the  system  can  be  revised  and  restructured  as 
necessary  until  ultimately  it  is  accepted  as  a  viable 
industry-wide  standard. 

This  project  is  intended  to  be  an  initial  step  toward  a 
thorough  study  of  tne  CORE  grapnics  system  at  tne  Naval 
Postgraduate  School.  The  long  term  goal  of  the  research  is 
to  Implement  the  GSPC  proposed  system  on  tne  grapnics 
facility  at  the  Naval  Postgraduate  School  and  critically 
examine  its  performance. 

When  this  research  was  begun,  exposure  to  CORE  at  the 
Naval  Postgraduate  Scnool  was  limited  to  tne  information 
available   in   the   literature.   No  version  of  it   was 
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operational  at  the  facility.  It  was  expected  that  the 
progress  of  the  worn  would  be  slow  wnile  experience  with 
CORB  was  being  accumulated.  Since  this  study  was  the  initial 
step,  the  emphasis  was  placed  on  producing  a  good  foundation 
for  work  that  would  follow. 

Naturally,  the  first  step  in  the  study  of  CORE  was  to 
implement  a  version  of  it.  The  PDP-11/50  computer  and  RSX- 
11M  operating  system  were  the  target  environment  for  this 
pnase.  The  CORE  software  was  Bell  Northern  Researcn's 
Virtual  Gra2hi£S  flac.hlne  LlSfll*  which  was  donated  by  that 
company  to  the  Naval  Postgraduate  School  for  research 
purposes.  A  detailed  report  on  the  system  installation  is 
presented  in  Appendix  A. 

An  intermediate  goal  of  the  project  is  to  extend  the 
newly  installed  CORE  system  to  a  variety  of  devices.  Toward 
this  end  the  initial  steps  were  taken  to  incorporate  an 
interface  with  the  Ramtes  RM-9400  graphics  display  system 
into  the  CORE  software.  Appendix  fl  describes  this  portion  of 
tbe  research. 

As  part  of  building  a  knowledge  base  for  later 
researcn,  the  CORE  system  and  its  development  are  discussed 
in  detail.  The  discussion  is  intended  to  give  enough  of  an 
overview  of  the  system  so  that  tne  reader  will  not  need  to 
refer  to  the  source  documents  except  for  essential  details. 
An  examination  of  the  relationship  between  7GM 
implementation  and  tbe  CORE  specification  is  also  provided. 


1 1 .   IIS TORI 

A.   THE  PROBLEM  Of   NON-STANDARDIZED  GRAPHICS  SYSTEMS 

Until  the  mid  1970's  individual  graphics  devices  were 
operated  witn  their  own  specialized  software  systems  and 
tbeir  instruction  sets  were  tailored  to  their  own  particular 
capabilities.  Programming  techniques  generally  were 
constrained  by  the  device  characteristics.  Even  program 
structure  could  be  dictated  by  the  available  grapnics 
system.  Added  to  these  restrictions  would  be  additional 
requirements  associated  with  installation  computing  hardware 
and  operating  systems.  Such  highly  individualized  equipment 
meant  that  each  graphics  system  required  specialized 
programs,  and,  in  general,  tnese  were  applicable  for  tnat 
installation  and  no  other. 

As  the  field  of  computer  grapnics  expanded,  sucn 
limitations  became  a  real  liability.  The  inability  to  use 
one  program  at  more  than  one  installation  meant  that  for  a 
given  application  a  new  set  of  software  would  nave  to  be 
developed  individually  for  each  combination  of  hardware  and 
operating  system.  The  issue  of  non-portability  eventually 
became  an  overriding  concern  of  the  industry. 

If  the  programs  for  particular  devices  were 
individualized  then  so  was  the  training  of  the  programmers. 
Every  device   required  users   to   nave   fairly   extensive 
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knowledge  of  its  operation.  Rattier  than  concentrate  on 
eraphics  in  a  broad  spectrum,  application  programmers  *ot 
involved  in  very  low  level,  nighly  detailed  programming  for 
a  specific  device.  This  meant  that  much  of  the  knowledge  and 
tecnniques  developed  by  a  programmer  mignt  be  unuseable  if 
the  device  were  changed.  Thus,  a  hardware  cnange  brougnt 
with  it  the  necessity  for  an  in-depth  training  program  on 
the  new  device.  Furtner,  tne  programmer  would  now  nave  to 
keep  the  operating  details  of  each  device  separate  in  his 
mind.  Confusion  of  sucn  details  is  hlgnly  conducive  to  tne 
introduction  of  additional  bugs  into  programs. 

The  prospect  of  working  in  a  very  restricted  environment 
and  of  being  required  to  assimilate  and  differentiate  a  host 
of  idiosynchrasies ,  mnemonics,  formats  and  operational 
details  no  doubt  caused  many  potential  grapnics  application 
programmers  to  turn  to  other  fields  of  specialization.  The 
graphics  industry  must  count  this  to  its  detriment. 

Another  problem,  perhaps  not  quite  as  visible  as  the 
portability  issues,  but  certainly  as  worthy  of  concern,  was 
the  difficulty  researchers  in  graphics  had  in  building  on 
one  another's  work.  An  application  written,  for  example,  for 
a  storage  tube  display,  would  have  to  be  completely 
rewritten  for  a  raster  device.  The  changes  would  be  so 
numerous  tnat  equivalence  of  tne  programs  would  be 
impossible  to  assert.  Also,  the  full  duplication  of  a  piece 
of  work  simply  to  adapt  it  to  a  different  environment  was   a 
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costly  process  in  terms  of  time  and  resources,   botn  human 
and  machine. 

B.   FORMATION  OF  THE  GSPC 

In  more  recent  years,  tnere  nave  been  some  attempts  to 
remove  tne  user  from  tne  details  of  device  operation  by 
providing  nigh  level  software.  This  typically  too*  the  form 
of  a  package  of  subroutines  callable  from  some  standard  nigh 
level  language.  Such  packages  did  remove  the  need  for 
programmer  Knowledge  of  some  of  the  device  operating  details 
(though  by  no  means  all  of  them)  but  each  package  was  still 
unique.  Thus,  though  a  step  forward  had  been  made,  programs 
written  from  different  grapnics  packages  were  still  not 
portable. 

The  next  step  in  tne  evolution  was  to  develop  grapnics 
packages  that  were  still  specific  for  particular  graphics 
devices  but  with  a  standard  interface  to  the  user  program. 
This  would  allow  transportation  of  user  programs  unchanged 
to  installations  where  the  "standard"  interface  was 
implemented.  This  development  was  moderately  successful  out 
by  this  time,  areas  of  research  had  grown  up  around 
particular  classes  of  graphics  devices.  User's  of  tne 
various  classes  of  devices  all  had  their  own  idea  as  to 
exactly  what  form  the  application  program  interface  should 
take.  Tnese  opinions  were  widely  varying  and  as  always,  were 
oriented  toward  the  device  capabilities. 
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The  various  scnools  of  grapnics  research  eventually 
realized  that  there  were  wile  areas  of  agreement  in  their 
concepts  of  how  a  user  should  see  a  grapnics  system.  This 
led  to  the  next  evolutionary  stride,  the  standardized 
graphics  package.  These  types  of  systems  were  designed  so 
that  not  only  would  the  application  program/package 
int;rface  be  fixed,  but  the  functionality  of  the  package 
itself  would  be  uncnanging.  The  need  for  individualized 
software  for  each  particular  device,  however  would  not  be 
removed.  This  task  would  be  accomplished  by  a  "device 
driver"  and  its  interface  with  the  standard  package  would  be 
a  fixed  entity. 

The  first  Tieaningful  steps  toward  a  standard  graphics 
package  was  the  IFIP  Working  Group  5.2  Graphics 
Subcommittee's  Workshop  on  Grapnics  Methodology  held  in 
Seillac,  France  in  1976.  Based  on  experience  with  existing 
machine  and  device  independent  packages  like  GINO-F  and  GPGS 
the  subcommittee  laid  the  groundwork  for  the  movement  toward 
industry  wide  standardization.  Their  contribution  was  to 
outline  and  define  the  issues  tnat  had  to  be  addressed  if  a 
standard  was  to  become  a  reality.  As  already  discussed, 
their  prime  concern  was  tne  issue  of  application  program 
portability.  Toward  this  end  their  recommendation  was  that  a 
study  of  the  structure  of  application  programs  was 
indispensable,  and  that  the  results  of  such  a  study  would 
drive   the   specification  of  a   graphics   standard.   Another 
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outcome  of  tne  Seillac  meeting  was  tne  assertion  tnat  tne 
separation  of  operations  concerned  with  creating  a  picture 
of  an  object  from  those  concerned  with  manipulating  tne 
object  itself  was  essential.  Lastly,  the  Workshop  urged  that 
a  standard  graphics  system  specification  not  stand  alone. 
Along  with  the  detailed  design  should  be  included  the 
methodology  behind  its  development. 

In  1977  tne  ACM  Special  Interest  Group  for  Grapnics 
(SIGGRAPH)  appointed  a  Grapnics  Standard  Planning  Committee 
to  design  an  industry  wide  graphics  standard.  Using  the 
recommendations  of  the  Seillac  rforfcshop  as  a  foundation,  the 
GSPC  designed  tne  CORE  graphics  system.  Their  specification 
for  the  system,  and  the  methodology  that  led  to  it,  were 
published  in  August  1977.  An  updated  version  appeared  two 
years  later  incorporating  the  experience  gained  in  the 
interim  and  extending  CORE  to  raster  devices. 
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III.  ISSUES  CONSIDERED  IN  CORE  DESIGN 

In  tne  early  stages  of  discussion,  tne  Grapnics 
Standards  Planning  Committee  concentrated  on  clearly 
defining  tneir  goal.  Tneir  objective  was  to  design  a  general 
purpose  graphics  system  tnat  would  meet  the  needs  of  tne 
majority  of  graphics  programmers  and  would  be  simple  to 
install  on  most  existing  interactive  displays. 

It  is  essential  that  such  a  general  purpose  system  be 
simple.  Tnis  principle  was  recognized  by  tne  GSPC  and 
strictly  adhered  to.  They  targeted  their  efforts  toward  the 
potential  users  with  tne  intention  of  promoting  well- 
structured,  comprehensible  software.  Syntax  was  considered  a 
less  complex  and  secondary  design  issue.  The  committee  also 
sought  to  put  definite  bounds  on  the  scope  of  the  new 
system.  The  intention  was  to  provide  a  system  tnat  would 
offer  a  wide  range  of  capabilities,  but  not  at  the  cost  of 
losing  its  appeal  as  a  areneral  purpose  tool.  Two  tradeoffs 
that  constantly  cropped  up  before  tne  GSPC  were  simplicity 
vs.  wide  applicability  and  program  portability  vs.  machine 
efficiency. 

A.   FORMAT  OF  CORE 

Tne  GSPC  considered  tnree  approacnes  to  development  of 
the   core  system.   One  possibility  was  to  create  a   complete 
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new  srraphics  language.  A  second  cftoice  was  to  take  an 
existing   language  and  make  tne  core  system  an  extension   of 

it.  The  third  approach,  and  the  one  finally  settled  upon  was 
to  build  a  package  of  graphics  subroutines.  There  are  a 
number  of  advantages  to  the  subroutine  package  as  opposed  to 
either  of  the  alternatives.  Tne  major  benefit  is  that  it 
requires  no  changes  to  either  the  language  or  the  compiler. 
System  development,  revision,  and  experimentation  will  have 
no  effect  on  any  other  software  at  tne  installation.  The 
primary  limitation  is  that  the  syntactic  structure  is 
extremely  limited  since  the  only  choice  in  tnis  area  is  the 
approach  to  parameter  passing. 

B.   DEGREES  OF  PORTABILITY 

The  degree  of  program  transportability  as  measured  by 
the  type  of  required  changes  was  broken  do*n  into  three 
general  categories: 

1)  The  absolutely  portable  program  which  wnen 
transferred  fron  one  installation  to  anotner  would  require 
no  changes  whatever  to  the  source  code.  Such  programs  are 
the  ultimate  goal  of  any  grapnics  standard. 

2)  Programs  that  require  only  editorial  changes  without 
modification  of  structure.  This  class  of  program  would 
require  adaptation  to  a  new  installation  in  much  the  same 
way   that   non-grapnics   programs  written  in  a  hign   level 
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laneua*e  have  to  be  modified  when  they  are  transported.  The 
changes  typically  are  those  necessary  to  adapt  to  such  local 
idiosynchrasies  as  different  character  sets.  These  changes 
do  not  require  a  grapnics  programmer  or  a  specialist  in   the 

particular  application.  Many  of  them  can  even  he  automated 
on  a  reasonably  good  text  editor. 

3)  The  least  portable  category  of  programs  would  be 
those  where  changes  to  the  program  structure  itself  are 
required.  Such  changes  as  naving  to  create  a  particular 
routine  to  draw  an  arc  to  replace  a  single  command  required 
by  a  more  powerful  device  fall  into  this  category.  Changes 
of  this  type  may  require  a  detailed  Knowledge  of  tne 
particular  installation  characteristics?  even  then  they  can 
be  somewhat  difficult  and  have  a  tendency  to  be  error  prone. 

Realization  of  the  absolute  portability  goal,  was  not 
expected  when  the  GSPC  publisned  their  proposal.  The 
immediate  hope  for  the  CORE  system  is  that  it  will 
drastically  reduce  tne  number  of  cnanges  required  in  an 
application  program  wnen  it  is  transported.  It  is 
anticipated  tnat  tne  "routine"  changes  of  category  2  above 
will  be  required  in  source  code  but,  as  a  minimum,  the 
structure  of  the  source  program  should  remain  intact. 

C.   SCOPE  OF  CORE 

Havins  established  the  form  the  roposed  graphics 
standard  would  tajie,   and  tne  results  tnat  could  be  expected 
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from  it,  the  committee  set  about  defining  the  scope  of  the 
project.  Recognizing  the  Seillac  workshop's  wisdom,  the  G-SPC 
focused  on  "viewing"  as  the  essential  part  of  any  graphics 
system  (its  cor*,  hencs  the  name)  and  treated  anything  not 
concerned  strictly  with  displaying  information  about  an 
object  as  outside  the  scope  of  the  standard.  This  is  not  to 
say  that  such  issues  as  modelling  or  grapnic  arts  were 
ignored.  The  intent  was  to  design  a  core  viewing  system 
upon  which  tnose  functions  dealing  with  abstract  objects  and 
relations  between  them  could  be  built. 

D.   flEWING-  SYSTEM  CONCEPTUAL  MODEL 

Once  the  scope  of  their  task  was  defined,  the  committee 
developed  a  model  that  would  adequately  represent  their 
concept  of  the  viewing  system  of  tne  standard.  Tne  viewing 
system  can  be  thought  of  as  a  "synthetic  camera"  positioned 
and  oriented  in  a  user  defined  "world  coordinate  system". 
The  display  on  the  output  dsvice  would  be  a  "snapshot"  of 
whatever  was  in  tne  camera's  field. 

Such  an  analogy  fit  well  the  rules  the  SSPC  had 
formalized.  Tne  "grapnical  world"  was  considered  all  of  tne 
graphical  data  available  to  the  system.  What  would  show  up 
on  tne  output  device  would  be  a  view  of  tnis  world  tnrougn 
the  eye  of  the  synthetic  camera.  The  camera  might  be  able  to 
taice  in  the  entire  set  of  graphical  data  or  only  a  portion 
of   it,   depending   on  the  viewing  parameters.   To   taJce   an 
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imaginary  snapshot,  the  system  would  nave  to  be  aware  of  the 
camera's  location  in  space,  its  orientation,  and  tne  amount 
of  a  particular  object  it  could  actually  photograph  (i.e. 
its  clipping  volume).  Further,  at  tne  instant  tne  snapshot 
is  taken,  none  of  the  parameters  related  to  the  object  beine- 
photograpned  could  cnange.  It  must  be  remembered  tnat  what 
is  on  the  screen  is  only  a  part  of  the  total  information  in 
tne  grapnical  world. 

E.   GRAPHICAL.  DATA  STRUCTURE 

Besides  deciding  how  to  display  an  object  in  the 
graphical  world  the  committee  had  to  establish  the 
particular  structure  to  be  used  to  represent  grapnical  lata. 
The  simplest  approach  would  be  to  have  no  structure  at  all. 
Either  all  of  the  graphical  data  is  present  and  fixed  or  a 
new  graphical  world  will  have  to  be  created.  Thus,  one  could 
only  build  or  erase  an  entire  object.  One  displayed,  there 
would  be  no  changes  to  tne  graphical  world.  Such  an  approach 
is  very  easy  to  implement  and  storage  is  not  a  major  issue, 
since  after  tne  snapshot  is  tatcen,  there  is  no  further  need 
of  the  data.  Such  a  system  is  ideally  suited  to  hard-copy 
plotters  and  similar  devices  but  its  drawback  is  that  it 
does  not  meet  the  needs  of  a  large  portion  of  graphics 
applications . 

Much  of  graphics  is  concerned  with  buildin*  an  object 
and   selectively  modifying  only  parts  of  it.   This   requires 
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first,  that  the  graphical  data  not  be  lost  after  it  is 
displayed   and  second,   that  it  be  "segmented"  in  such  a  way 

that  individual  pieces  can  be  manipulated.  Since  there  is  a 
considerable  demand  for  sucn  structuring,  the  GSPC 
incorporated  it  into  their  standard  proposal.  Their  concept 
is  that  graphical  primitives  (line  drawing,  text,  and  marker 
placements)  be  grouped  into  indivisible  and  unchangeable 
segments .  Tnese  segments  are  then  be  combined  to  produce  an 
entire  object.  Thus  the  picture  can  be  modified  by  pieces 
through  the  deletion  and  addition  of  individual  segments. 

In  the  interest  of  economy  and  flexibility  the  CORE 
system  also  implements  a  form  of  the  simpler  unstructured 
option.  For  the  body  of  users  concerned  with  storage 
efficiency  or  having  hardcopy  displays,  it  is  possible  to 
designate  segments  as  temporary.,  A.  temporary  segment  is  one 
that  would  generate  graphical  output  while  it  is  open,  but 
once  closed  the  segment  would  be  automatically  deleted.  The 
next  "new  frame"  action  will  cause  it  to  be  lost  altogether. 
Effectively,  while  the  image  is  being  created  in  the  open 
temporary  segment  the  graphics  system  is  unstructured. 

Another  possible  structuring  of  graphical  data  would  be 
to  use  multi-level  units  to  define  tne  grapnical  world.  In 
such  a  system,  a  "unit"  (analogous  to  a  segment)  would  be  a 
collection  not  only  of  primitives  but  also  of  references  to 
other  units.   This  approach  was  considered  by  the  GSPC  to  be 
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to  complex  for  the  bullc  of  current  graphics  applications. 
There   are  many  variations  to  its  implementation,   none   are 

easily  accomplished,  and  all  require  a  great  deal  of 
boofciceeping  overhead  since  a  change  to  one  unit  may  ripple 
through  several  others  that  reference  it.  It  should  be  Icept 
in  mind,  novever,  tnat  if  such  a  grapnical  structure  is 
desired  it  is  possible  to  construct  it  using  tne  CORE 
system. 

F.   ATTRIBUTES 

With  the  structure  of  grapnical  data  settled  upon,  the 
need  arose  for  defining  modifications  to  the  described 
object.  Besides  the  primitive  functions  already  mentioned,  a 
graphics  system  must  have  a  means  of  further  describing 
them.  For  example,  a  primitive  lifce  "line"  mignt  nave 
characteristics  such  as  dashed  (style),  red  (color),  and 
double  thickness  (widtn).  Deciding  now  to  incorporate  such 
§li£ibuies  iQto  CORE  was  another  major  issue  facing  GSPC. 
Some  attributes  naturally  associate  themselves  with 
primitives,  liKe  line  style  and  width,  while  others  just  as 
naturally  only  apply  to  wnole  segments,  sucn  as  viewing 
angle  or  clipping  volume.  A  problem  arises  with  attributes 
that  are  lively  to  be  needed  for  botn  primitives  and 
segments.  Color  is  a  typical  example.  The  ability  to  produce 
a  drawing  using  lines  of  several  different  colors  might  be 
desirable.   But   if   it  is  desired  later  in  the   program   to 
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change  the  color  of  all  drawings  to  say  blue,  an  ambiguity 
arises  in  now  to  nandie  tne  multicolored  segment. 

The  GSPC  felt  that  resolution  of  such  ambiguities  within 
CORE  would  taice  away  from  tne  simplicity  of  tneir  system. 
Therefore  they  established  the  rule  that  no  attributes  would 
be  shared.  Attributes  would  be  specific  for  primitives  only 
or  for  segments  only.  The  former  would  be  "static" 
attributes  and  be  unchangeable  for  a  primitive  once 
declared.  Segment  attributes,  on  the  other  nand  would  not  be 
so  restricted.  These  "dynamic"  attributes  would  be 
changeable  to  meet  tne  user's  needs  at  any  particular  place 
in  tne  program. 

The  decision  as  to  Just  which  attributes  would  be  static 
and  wnich  would  be  dynamic  were  based  on  two  criteria.  Tne 
first  bein*  that  primitive  attributes  would  be  those  things 
that  would  normally  be  recorded  by  a  snapshot  of  a 
particular  object.  Attributes  pertaining  to  the  image  as  a 
wnole  would  be  segment  attributes.  The  second  criteria  was 
that  an  attribute  would  be  dynamic,  (i.e.  a  segment 
attribute)  only  if  most  medium  performance,  refresned 
display  device  architectures  supported  cnanging  tne 
attribute  with  reasonable  ease  and  efficiency. 

G.   TWO  AND  THREE  DIMENSIONAL  GRAPHICS 

Along  with  the  questions  of  graphical  data  structure, 
tne   issue  of   now  to   treat   two-dimensional   and   tnree- 
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dimensional  graphics  in  a  single  standard  had  to  be  decided. 
Initially  tne  inclusion  of  three-dimensional  grapnics  was  in 
question  since  it  necessarily  would  add  complexity  to  the 
system.  It  was  decided  that  tne  need  for  three-dimensional 
grapnics  was  great  eaougn  tnat  its  exclusion  would  restrict 
tne  applicability  of  tne  standard  to  an  undesirable  desree. 

A  more  subtle  question  than  3D  inclusion  was  whether  to 
treat  2D  grapnics  as  a  subset  of  3D  or  to  handle  the  two  as 
disjoint  sets  of  operations.  The  advantage  of  disjoint 
treatment  is  tnat  tne  2D  expression  would  not  be 
unnecessarily  complex  since  3D  information  would  not  have  to 
be  carried  with  tnem.  On  tne  other  hand  a  large  portion  of 
the  system's  routines  would  have  to  be  duplicated,  one  sroup 
specialized  for  2D  manipulation  and  another  for  3D. 

The  GSPC  chose  the  subset  approach  in  the  interest  of  a 
unified  treatment  for  all  images.  To  foster  simplicity  in  2D 
graphics,  they  established  that  the  z  axis  coordinate  would 
automatically  default  to  that  of  its  last  specified  value 
when  fitting  2D  operations  into  the  3D  format. 

H.   ?ISVING  TRANSFORMATIONS 

One  of  the  most  difficult  issues  for  the  GSPC  to  decide 
was  how  to  treat  viewing  transformations  of  an  object.  There 
are  a  large  number  of  approaches  to  this  problem  and  all 
have  a  certain  amount  of  merit.  When  considering  this 
particular  question  the  committee  chose  to  aim  for  maximum 
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system  generality.  Toward  this  end,  they  established  four 
criteria.  The  first  was  that  any  viewing  transformations  to 
be  performed  would  be  declared  before  description  of  a 
particular  object.  No  transformations  within  a  segment  would 
be  allowed.  Secondly,  two-dimensional  transformations  would 
be  upward  compatible  to  three-dimensional  ones.  Third,  all 
general  planar  projections  would  be  possible  to  implement. 
Fourth,  parallel  and  perspective  projections  would  be 
consistent . 

In  tne  discussion  of  viewing  it  is  necessary  to  go  bacu 
to  the  synthetic  camera  model.  In  order  to  maximize 
generality  of  the  viewing  aspect  of  CORS  the  parameters 
under  investigation  were  those  concerning  the  location  of 
the  synthetic  camera  in  space  and  tne  location  of  tne 
viewing  plane.  The  orientation  of  both  the  camera  and  the 
viewing  plane  must  also  be  considered.  It  should  be  apparent 
that  the  most  flexible  viewing  system  is  the  one  that  allows 
any  orientation  and  any  location  for  both  the  camera  and  the 
viewing  plane.  Restricting  the  positioning  of  one  or  both, 
limits  the  allowable  viewing  pyramid  and  results  in  failure 
to  meet  one  or  more  of  the  established  criteria. 

For  example,  suppose  the  view  plane  were  restricted  so 
that  it  must  always  be  normal  to  the  direction  in  which  the 
camera  is  aimed.  In  such  a  case,  oblique  perspectives  are  no 
longer  possible,  which  is  a  violation  the  third  criterion. 
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I.   LEVELS  OF  CORE 

One  of  the  final  issues  to  be  resolved  was  tne  structure 
of  tne  CORE  standard  itself.  Tne  question  was  wftetner  to 
establisn  a  single  monolitnic  standard  or  to  allow  a  number 
of  "standard  subsets"  of  a  parent  system.  Realizing  that  a 
very  extensive  system  might  be  well  beyond  the  needs  and/or 
resources  of  many  installations,  tne  GSPC  settled  on  a  three 
level  structure.  The  lowest  level  would  be  restricted  to  the 
most  basic  needs  of  most  users,  stressing  ease  of 
implementation  as  well  as  economy  of  computing  resources. 
The  upper  two  levels  include  more  features  and  a  higher 
capability  with  correspondingly  more  difficulty  in 
implementation.  Each  upper  level  of  CORE  includes  all  of  the 
features  of  tne  level  below  it. 
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IV.  CORE  SYSTEM  DESCRIPTION 

A.   OVERVIEW 

In  tne  previous  chapter  most  of  the  basic  terminology  of 
CORE  has  been  introduced.  In  this  chapter  tne  system  itself 
is   discussed   in  detail,    but   before  doin^  so,    more 

terminology  must  be  introduced.  Tne  information  displayed  on 
the  graphics  display  device  is  referred  to  as  a  picture.  T!ie 
basic  building  bloclcs  of  pictures  are  output  j>rimi t i v es  .  An 
output  primitive  is  a  line  or  sequence  of  lines,  a  non- 
drawing  move  of  the  cursor,  a  marlcer  placement,  or  a  string- 
of  text.  A  number  of  output  primitives  are  grouped  together 
to  form  a  segment.  Each  segment  defines  a  single  object  and 
a  combination  of  one  or  more  objects  defines  an  image.  The 
view  of  an  image  can  be  thought  of  as  a  imaginary  camera 
snapshot  of  it.  To  obtain  a  3-D  projection  of  an  image  the 
user  specifies  the  imaginary  camera  position,  type  of 
projection  (perspective  or  parallel)  and  where  on  the 
display  surface  the  object  is  to  appear.  Different  views  are 
obtained  by  "moving"  the  synthetic  camera  in  space  relative 
to  the  stationary  object.  After  the  view  of  an  image  is 
determined  the  graphics  system  must  map  it  onto  the 
particular  device  selected  to  show  it.  The  CORE  system  does 
this  using  two  coordinate  systems.  Objects  and  images  are 
created   in  a  user  defined,   previously   specified   Vor,ld 
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Coordin^ie  System.  Within  this  coordinate  system  the  part  of 
the  total  image  that  is  to  be  displayed  is  framed  by  a 
window.  The  World  Coordinate  System  is  mapped  Dy  CORE  onto  a 
set  of  normalized  device  co.ordina.tgs  iNDCl.  NDC 
specification  defines  tne  viewing  area  on  the  selected 
graphics  device  that  will  be  used.  NDC's  are  specified  as 
fractions  of  the  total  available  display  widtn  and  height. 
The  window  and  the  visible  section  of  the  image  in  it  are 
mapped  to  the  corresponding  location  in  the  normalized 
device  coordinates.  Once  the  image  is  in  in  terms  of  the  NDC 
it  is  a  simple  matter  for  tne  CORE  system,  Knowing  tne 
particular  device  characteristics,  to  translate  it  into  a 
picture  on  the  screen. 

Any  graphics  system  must  nave  a  means  of  controlling  its 
operating  environment.  In  the  CORE  system  this  is 
accomplished  by: 

1)  turning  clipping  on  or  off 

2)  selecting  view  surfaces  for  output 

3)  setting  initial  values  for  segment  and 
primitive  attributes. 

4)  establishing  error  handling  mechanisms 

To  support  the  control  functions  the  application  program  is 
given   tne   capability  to  inquire  about  the   system   status, 
variables  and  device  capabilities.  There  is   a  "new  frame" 
function   for  screen  clearing  and  a  capability  for  grouping 
changes  to  the  picture. 
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Output  primitive  functions  may  be  referenced  eitner  by 
a  segment  identifier  or  a  special  "pick-id"  name.  The  picfc- 
id  is  used  in  conjunction  witn  a  pict  device,  wnicn  will  be 
discussed  later  in  tne  chapter. 

To  allow  utilization  by  tne  system  of  specific  nardware 
and  installation  features,  tnere  is  an  escape  mecnanism.  It 
is  a  standard,  rigorously  constrained  function  tftat  allows 
tne  CORE  system  to  taxe  advantage  of  tne  non-standard 
capabilities  of  its  environment.  Use  of  the  escape  has  a 
price  in  that  it  tajtes  away  from  the  portability  of  the 
application  program. 

B.   OUTPUT  PRIMITIVE  FUNCTIONS 

Output  primitive  functions  are  tae  operations  the 
programmer  uses  to  describe  objects  in  the  device- 
independent  World  Coordinate  System.  Invocations  of  these 
functions  are  gathered  into  segments  as  drawing  commands. 
Primitives  wort  from  the  current  p.ositi.on  iCPl,  which  is  a 
drawing  location  in  world  coordinates.  It  is  simply  a 
starting  point  for  application  of  the  function,  and  is 
Initialized  to  the  origin  upon  segment  creation. 

There  are  five  output  primitives:  single  and  multiple 
line  drawings,  text  display,  and  single  and  multiple  marfcer 
placements.  These  are  only  slightly  different  for  the  two- 
and  three-dimensional  versions.  Coordinate  positions  may  be 
specified  as  either  relative  or  absolute,   but  tne  former  is 

29 


merely  a  notational  convenience.  It  does  not  necessarily 
generate  a  relative  positioning  command  to  the  nardware.  Tne 
concept  of  a  marfcer  in  tne  CORE  system  is  simply  a 
designation  of  a  position  in  world  coordinates.  A  particular 
character  appears  on  tne  view  surface  to  indicate  tnis 
position  but  in  world  coordinates  tnere  is  no  sucn 
cnaracter. 

Tnree  Kinds  of  text  are  supported  by  tne  CORE  system 
output  primitives:  string  precision,  character  precision 
and  strode  precision.  Tne  main  purpose  of  string  precision 
text  is  to  supply  information  to  tne  operator.  Its 
generation  is  simple  and  efficient.  Cnaracter  precision  text 
is  used  when  it  is  important  that  a  character  string  occupy 
a  designated  space,  a  plot  axis,  for  example.  String  and 
character  precision  are  also  referred  to  as  low  and  medium 
quality  text,  respectively.  Both  medium  and  low  quality  text 
output  primitives  tafce  advantage  of  hardware  character 
generators,  if  available.  StroJte  precision,  or  nign  quality 
text  requires  a  different  approach.  Here,  tne  string  is 
treated  as  if  each  line  of  each  character  were  generated  by 
software  in  the  CORE  system. 

C.   SEGMENTS 

Segments  are   created   in   the   applications   program. 

Creation  of  a  segment  follows  a  simple  sequence.   Tne  World 

Coordinate  System   is   defined  and   normalized   device 
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coordinates  are  specified.  If  desired,  tne  synthetic  camera, 
discussed  earlier,  is  positioned  to  establish  the  view  of 
tne  object.  Next,  a  segment  is  "opened"  and  tne  object 
described  using  the  output  primitives.  After  completing  the 
object  description,  tne  segment  must  be  "closed  ".  To  modify 
a  piece  of  the  picture  a  segment  is  deleted  and  a  new  one 
created  to  replace  it.  Segments  are  of  two  types:  l) 
retained,  wnicn  are  typically  used  for  buffered  displays  and 
2)  lemp.orar^,  which  are  most  often  used  by  plotters.  As  one 
might  infer,  temporary  segments  are  used  only  once  to  create 
a  display  and  then  are  discarded.  Retained  segments  are  Jtept 
by  the  CORE  system  until  specifically  deleted.  Temporary 
segments  have  the  advantage  of  economy  of  memory 
utilization.  A  segment's  type  is  established  wnen  it  is 
created  and  remains  unchanged  for  the  life  of  the  segment. 
Copying  one  segment  into  another  or  invoking  one  segment 
from  another  is  not  permitted  under  the  CORE  system. 

D.   ATTRIBUTES 

The   effects   of   output   primitives   are  modified    by 

assigning  attributes  to  tnem.   For  example,  the  primitive 

"line"  has  an  attribute  "linestyle"  which  has  values  "solid" 

and  "dashed".   Other  attributes  that  apply  to  primitives  are 

color,  character  size,  character  precision,  linewidth  and 
more. 
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Segments,  lite  output  primitives,  also  nave  attributes. 
These  control  such  things  as  a  segment's  visibility, 
nignlighting  witnin  the  segment  and  its  detectability  by  a 
pick  device.  This  last  is  a  particularly  important  segment 
attribute.  When  a  segment  is  detectable  and  a  picfc  is 
enabled,  the  device  can  select  a  primitive  from  tne  segment 
and  return  to  the  application  program  both  the  segment  name 
and  the  primitive's  glcfc-ld. 

With  the  exception  of  type,  segment  attributes  are  all 
"dynamic"  in  that  they  may  be  changed  after  the  segment  has 
been  created.  If  tne  user  does  not  specify  attribute  values 
prior  to  segment  creation,  tne  CORE  system  provides  a  set  of 
default  values. 

Segments  are  assigned  attribute  values  from  a  table  of 
current  attribute  values  maintained  by  the  system.  The 
application  program  has  the  capability  to  interrogate  and 
change  attributes.  For  primitive  attributes  changes  can  only 
be  made  while  the  segment  is  open;  segment  attributes,  on 
the  other  hand,  may  be  changed  at  any  time.  A  single 
attribute  cannot  apply  to  both  primitives  and  segments.  If 
certain  attributes  are  not  supported  by  hardware,  the 
options  are  to  either  simulate  tnem  or  force  a  reference  to 
an  error  handling  routine.  The  choice  is  installation 
dependent. 

Besides  segment  and  primitive,  attributes  can  be 
classified   by   the   "space"   in  which   they   operate.   For 
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example,  teit  attributes  describe  tne  text  regardless  of  its 
location  or  orientation.  They  are  said  to  define 
characteristics  in  "object  space".  On  tne  otner  nand  ,  line 
attributes  such  as  style  and  width  are  related  to  views  of 
objects.  Depending  on  the  location  of  the  synthetic  camera 
tnese  attributes  of  an  object  may  appear  different  for  the 
same  value.  They  are  sail  to  operate  in  the  "picture  space". 

E.   VIEWING  TRANSFORMATIONS 

A  viewing  transformation  accomplishes  two  tasfcs:  it 
specifies  how  much  of  the  world  coordinate  space  is  visible 
and  it  maps  visible  world  coordinate  pictures  into 
normalized  device  coordinates.  The  viewing  transformation 
tases  a  world  coordinate  volume  (a  clipped  portion  of  a 
complete  display)  and  projects  it  onto  a  view  plane  in  world 
coordinates  defined  by  a  window.  Tne  projection  is  then 
mapped  into  a  normalized  device  coordinate  viewport,  and 
finally  to  the  physical  device  coordinates.  The  core  system 
avoids  a  problem  that  has  occurred  in  the  past  where  two- 
dimensional  objects  required  different  treatment.  2D  objects 
are  treated  as  a  subset  of  the  3D  objects.  When  a  Z 
component  is  not  specified,  a  default  to  the  Z  component  of 
the  current  position  is  effected. 

Window  rotation  or  inclination  is  a  common  requirement 
for  many  applications.  In  the  CORE  system  the  concept  is 
implemented  using  a  view-up.  vector.   This   vector   simply 
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points   to   tae  "straignt  up"  direction  for  tne  window   with 
respect  to  tne  world  coordinate  orthogonal  X,  T,  and  Z  axes. 

F.   INPUT  PRIMITIVES 

Six   types  of  input  devices  are  supported  by   tne   CORE 
system: 

PICKS:  identify  an  output  primitive  by  its  segment 
name  and  picic-id. 

LOCATORS:  provide  world  coordinate  values  for  a  position 

on  tae  view  surface. 

VALUATORS:  provide  a  scalar  value. 

KEYBOARDS:  provide  cnaracter  strings. 

BUTTONS:  provide  a  means  of  selecting  from  several 
alternatives. 

STROKES:  provide  a  series  of  positions  to  the 
application   program  in  normalized  device  coordinates. 

Input  for  interactive  graphics  is  accomplished  through 
logical  input  devices.  These  devices  are  a  specified 
abstractly  in  the  application  program.  The  program  defines 
and  controls  them  in  a  way  unaffected  by  the  hardware.  The 
CORE  system's  tasfc  in  interactive  graphics  is  to  connect 
logical  input  devices  to  an  available  piece  of  hardware  that 
will  accomplish  the  desired  function.  Logical  input  devices 
may  be  manipulated  in  the  following  ways: 

1)  Initialization/  termination 

2)  Enabling/disabling 
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3)  Event  queueine/  dequeueins> 

4)  Sampling 

5)  Associating  sampled  and  event  causing  devices  (tnis 
ties  values  provided  by  sampled  devices  to  events  caused  by 
eveDt-generating  devices) 

5)  Echo  control 

Logical  input  devices  fall  into  two  mutually  exclusive 
categories.  Tney  are  eitner  sampled  devices  or  event  causing 
devices.  Strolte,  picfc,  Keyboard  and  button  are  event 
generating  devices?  locator  and  valuator  are  sampled 
devices.  Event-causing  devices  provide  signals  to  tne 
application  program.  For  each  event,  an  event  report  is 
created  containing  data  related  to  tne  state  of  the  device 
at  tne  time  of  tne  event.  Tne  CORE  system  enters  event 
reports  in  an  event  g.ueue  for  later  use  by  tne  applications 
program.  To  get  state  information  about  sampled  devices,  tne 
application  program  must  query  tnem.  Tnese  devices  do  not 
generate  event  reports.  A  standard  feature  of  tne  CORE 
system  is  to  ecno  automatically  all  operator  interactions 
unless  tnis  function  is   specifically  deactivated. 

5.   LEVELS  OF  CORE 

To  meet  tne  wide  range  of  installation  capabilities  and 
requirements,  an  upward  compatible  three-level  structure  for 
tne  CORE  system  was  selected.  Tne  aim  was  to  accomodate  wnat 
were   considered   the  most  common  classes  of   equipment   and 
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applications.  The  most  basic  level  of  tne  CORE  system  deals 
strictly  witn  output.  There  is  no  interactive  capability  and 
tne  segments  are  of  tne  temporary  type  only.  Tnis  level 
consists  of  tne  output  primitives  and  tneir  attributes, 
viewing  transformations  and  device  controls. 

Tne  next  level  adds  tne  ability  to  retain  selected 
segments.  It  still  is  limited  to  output  only  operation.  The 
visibility  and  highlighting  segment  attributes  also  are 
included.  Tne  third,  dynamic  level,  allows  use  of  tne  input 
capabilities.  This  is  the  level  at  which  interactive 
graphics  is  supported.  It  provides  all  the  functions 
intended  to  maice  up  the  complete  core  system: 

1)  Output  primitives  and  their  attributes 

2)  Viewing  transformations 

3)  Device  control 

4)  Temporary  and  Retained  segments  and  tneir  attributes 

5)  Input  primitives 

5)    Image   transformations 

Level  three  is  further  divided  according  to  the 
capability  for   imaee   transformation: 

3A)   Two-dimensional    translation   only 

3B)   Two-dimensional    translation,    rotation  and   scale 

3C )   Tnree-dirnensional    translation,    rotation  and   scale 
As   with  all   of   the  levels,      these   sub-levels   are  also  upward 
compatl ble. 
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Complications   with  such  a  level  structure  are  likely  to 

arise  at   installations  wnere  tnere  is   a   combination  of 

different   graphics  devices.   What  is  envisioned  for  such  a 

facility  is   a  body  of  device  independent   code   United  to 

individual  device  drivers.  The  intent  is  to  share  as  much  of 

the  independent  code  as  possible,  thereby  Keeping  as  much  to 
the  objective  of  probability  as  feasible. 

H.   ENVIRONMENT  INTERFACE  PROBLEMS 

Despite  a  £reat  deal  of  effort  to  make  the  CORE  system  a 
stand-alone  entity,  operating  systems  and  programming 
languages  still  impact  upon  it.  For  instance,  there  is  no 
standard  way  to  maire  device  driver  routines  available  to  the 
application  when  the  system  is  invoiced.  Methods  can  vary 
widely  depending  upon  computer  and  operating  system 
capabilities.  Another  problem  is  the  case  where  a  system 
message  is  sent  to  a  terminal  where  the  CORE  system  has  been 
invoked.  The  state  of  the  display  may  be  changed  without  the 
system  bein*  aware  of  it.  The  consequences  of  this  depend  on 
the  situation,  but  system  reliability  will  certainly  be 
degraded. 

There  is  as  yet,  no  definition  of  a  standard  interface 
with  programming  languages.  It  is  hoped  that  as  more  insight 
and  experience  is  gained,  a  standard  language  interface  will 
be  developed  and  the  CORE  system  will  be  able  to  be  invoked 
from  more  than  one  language,   adding  a  new  dimension  to   its 
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portability.   Input/output  also  has  problem  potential  if  the 

programming  language  and  the  CORE  system  are  operating   on 

the  same  device.  Resolution  of  this  is  still  highly  language 
and  device  dependent. 
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7.   THE  7GM  APPROACH  TO  CORE 

The  Lkrtual  Graphics.  Macnine  iVGMj.  is  Bell  Nortnern 
Research's  implementation  of  tne  CORE  graphics  system.  It 
was  developed  on  an  IBM  3033  in  ANSI  standard  FORTRAN  and 
later  modified  to  operate  on  a  PDP-11/70  under  the  RSX-11 
operating  system.  7GM  is  a  FORTRAN  based  set  of  subroutines 
with  each  subroutine  corresponding  to  a  CORE  primitive 
invocation,  attribute  setting,  or  view  transformation.  The 
pacfcage  also  includes  subroutines  for  control  purposes,  such 
as  initializing  devices,  opening  segments  and  setting  up 
coordinate  systems. 

The  intended  customer  marset  for  7GM  is  installations 
with  low  and  medium  cost  "intelligent"  terminals  which  are 
capable  of  generating  graphical  output  from  fairly  high 
level  functions  and  primitives.  Terminals  not  accepting  such 
high  level  input  will  require  intermediate  software  to 
eitner  simulate  the  functions  or  brea&  them  down  to  lower 
level  primitives  compatible  with  the  device. 

Under  RSX-11,  7GM  exists  as  a  library  of  FORTRAN 
subroutines.  To  use  7GM,  the  application  program  is 
created  Independently  as  a  main  program  making  calls  to  the 
7GM  library.  The  application  source  code  is  then  compiled 
independently.  The  connection  with  7GM  is  made  by  the  RSX-11 
Task   Builder.   The  application   object   file   and    tne 
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appropriate  routines  from  the  VGM  library  are  linked  into  a 
single  task  by  that  RSX  utility. 

Included  in  tfte  VGM  library  is  tne  particular  subroutine 
that  establishes  communication  between  VGM  and  the   selected 

device.  This  segment  of  code  has  to  be  created  specifically 
for  the  installation  where  VGM  is  to  be  implemented.  Tnis 
routine,  SELSTR,  is  the  only  executable  code  in  VGM  that 
interfaces  with  the  device  driver.  Grapnical  data  is  passed 
between  VGM  and  the  driver  via  a  COMMON  bloc*  of  memory. 
What  SELSTR  does  is  set  tne  necessary  flags  to  control  tne 
concurrency  between  the  application  tasic  (linked  with  VGM) 
and   the   selected  device  driver  tasks.   Each  device  driver 

exists  as  a  separately  compiled  and  linked  task.  Under  RSI, 
before  invoicing  any  driver  from  VGM  these  tasks  must  be 
INSTALLed  by  the  user. 

In  7GM,  syntax  is  a  very  minor  issue.  Since  the  parent 
language  is  FORTRAN,  and  the  entire  system  is  based  on  the 
subroutine  call,  the  only  syntax  is  the  manner  in  which  the 
necessary  parameters  are  passed. 

It  should  be  emphasized  that  7GM  does  not  implement   the 
CORE  graphics   system  exactly  as  set  down  in  the  1979  GSPC 
report.   There  are  a  number  of  differences,   wnlcn  may   be 
grouped  into  four  general  categories. 
A.   FUNCTIONAL  DIFFERENCES 

In  this  category  the  end  result  of  a  series  of 
operations  in  VGM  is  the  same  as  that  specified  by  CORE   but 
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the   mechanism   for   achieving   the  result  is   not   the   one 
specified  in  the  proposal. 
1 •  S egmen ta t io n 

The  CORE  system  creates  a  retained  segment  or  a 
temporary  segment  with  a  single  function  specific  for  the 
particular  segment  type.  VSM  uses  a  two-step  process.  First, 
a  segment  type  is  established.  After  the  invocation  of  the 
routine  to  do  tnis  any  segment  created  will  tatce  on  the  type 
of  the  one  declared.  All  segments  created  will  be  of  the 
same  type  until  a  new  type  is  declared. 

Retained  segments  in  7GM  are  stored  in  Transformed 
Display.  Files  iTDFlsJ..  The  TDF  contains  graphical 
information   that   is  ready  to  be  translated  into   a  device 

compatible  format.  All  clipping  and  transformation  has  been 
done  before  the  data  is  entered  in  tne  TDF.  Should  the 
application  program  specify  an  operation  on  a  segment,  the 
entire  TDF  is  lively  to  be  changed.  Segments  tnat  are 
specified  to  be  temporary  do  not  cause  creation  of  a  TDF. 

Like  CORE,  VGM  partitions  attributes  according  to 
their  application  to  either  segments  or  primitives.  Both 
systems  further  divide  the  set  of  attributes  according  to 
their  changeability  within  the  program,  dynamic  attributes 
being  tnose  that  are  subject  to  change  by  tne  application 
program   after   their   initial   declaration   and   static 
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attributes  being  those  that  are  not.  In  CORE  there  are  no 
dynamic  primitive  attributes.  VGM,  nowever,  does  have  a 
group  of  primitive  attributes  tnat  it  labels  as  "dynamic". 
Each  member  of  the  set  of  T5M  dynamic  primitive  attributes 
is  also  a  member  of  tne  set  of  static  primitive  attributes. 

In  7GM  a  static  primitive  attribute  is  one  that  is 
set  while  a  segment  is  open,  and  that  once  declared,  applies 
to  all  appropriate  primitive  invocations  following  it  until 
the  segment  is  closed.  Further,  for  the  lifetime  of  that 
segment  it  will  always  apply  to  the  set  of  primitives 
created  with  it.  A  static  primitive  attribute  cannot  be 
overridden  by  any  otfier  setting  of  that  attribute  anywhere 
in  the  program. 

If  no  attributes  applicable  to  a  particular 
primitive  are  set  within  a  segment  then  dynamic  primitive 
attributes  may  be  assigned  outside  tne  segment.  At  a  later 
time  in  the  program  these  attributes  may  be  changed.  When  a 
dynamic  primitive  attribute  is  set,  the  segments  to  which 
the  change  applies  must  be  specified.  If  tne  application 
program  does  not  set  either  dynamic  or  static  attributes  for 
some  primitives  then  default  values  are  used.  It  is  also 
possible  for  the  user  to  specify  his  own  set  of  default 
values . 

The  applicability  of  an  attribute  to  a  primitive  at  any 
particular  time  in  the  program  can  be  determined  by  the  rule 
that   user   specified  dynamic   primitive   attributes   always 
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override  default   values  and  static  primitive  attributes 
always  override  dynamic  ones. 
3.   Thj?  Viewing  Surface 

The  flow  of  graphical  information  from  a  segment  to 
an  output  device  is  viewed  by  VGM  as  a  "stream".  By 
manipulating  streams,  the  user  carries  out  the  CORE 
SELECT/DESELECT  and  ENABLE/DISABLE  device  operations.  In  VGM 
when  the  user  initializes  a  stream,  he  is  picking  a 
particular  device  or  group  of  devices  for  output.  Devices 
are  assigned  to  a  specific  stream  as  part  of  VGM.  A  given 
stream  may  have  more  than  one  device  associated  with  it. 
Changing  this  assignment  requires  changes  to  tne  VGM  source 
code  itself.  Stream  initialization  by  the  user's  subroutine 
calls  accomplishes  the  necessary  operating  system  functions 
to  lint  VGM  and  the  appropriate  drivers.  It  is  valid  for 
more  tnan  one  stream  to  be  in  use  at  any  given  time. 

After  initializing  the  required  treams  the  user 
then  selects  one  or  more  of  them  to  be  used  for  display. 
Once  a  stream  is  selected,  all  subsequently  generated 
graphical  output  will  be  displayed  on  the  devices  assigned 
to  that  stream  until  it  is  deselected.  There  is  no  way  to 
address  individual  devices  on  the  same  stream.  Stream 
operations  are  not  allowed  while  a  segment,  regardless  of 
type,  is  open. 
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*•   Coordinate  Systems 

7GM  uses  an  extra  coordinate  system  in  translating 
grapnical  data  from  world  coordinates  to  tne  terminal 
Pkliical  HSIiSS  Coordinates  iPDCl*  Between  tne 
transformation  from  World  Coordinates  to  Normalized  Device 
Coordinates,  VGM  taxes  clipped  grapnical  data  and  maps  it 
onto  a  view  plane  in  View  Plane  Coordinates  i?P£l.   The  flow 

of  eraphical  data  is  shown  in  Figure  1. 
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Figure   1.   Flow  of  graphical  information  through  coordinate 

systems 


5 .   Transformations 

In  the  CORE  specification  there  is  a  static  segment 
attribute  called  IMAG£_TRANSFORMATION_TTPE  this  specifies  a 
maximum  allowable  level  of  transformation  that  can  be 
applied  to  a  given  retained  segment.  Tnere  are  four 
allowable  levels: 

a.  no  transformation 

b.  2D  translation  only 

c.  2D  translation,  rotation  and  scale 

d.  3D  translation,  rotation  and  scale. 
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This  feature  is  not  included  in  VGM.  The  transformations  of 
2D  or  3D  translation,  rotation  and  scaling  may  be  applied  to 
any  retained  segment  at  any  time  in  the  program. 

6-   I5ZI  Manipulations. 

In  CORE,   the  manner  in  which  text  is  displayed  on  a 

device  is  controlled  by,  among  others,  the  attributes 
CHARPATH,  CHARJUST,  and  CHARUP.  The  first  attribute 
specifies  one  of  four  paths  in  the  view  plane:  up,  down, 
right  or  left.  As  the  sequence  of  text  is  output  CHARPATH 
determines  where  in  relation  to  the  last  character  the  next 
is  to  be  positioned.  The  first  character  is  always 
positioned  at  the  CP.  The  CHARJUST  attribute  is  a 
combination  of  directions,  again  in  the  view  plane,  which 
indicate  where,  in  relation  to  the  CP,  the  rectangle  defined 
by  the  output  text  string  is  to  be  placed.  Figure  2  gives 
the  possible  CP  locations. 
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Figure  2.  Possible  position  designations  of  CHARJUST 

The  text,   depending  upon  the  charjust  values  will  be  placed 
in  such  a   way  that  the  CP  will  be  at   a   junction   of  a 
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vertical  and  a  norizontal  line.  A  particular  junction  is 
identified  by  its  norizontal  and  vertical  position  labels, 
e.g.  "left,  top"  =  point  a;  "center,  off"  =  point  b.  The 
CHAROP  attribute  is  a  vector  from  the  origin  in  World 
Coordinates  which  specifies  the  "up"  direction  for  the  text. 
These  three  CORE  attributes  are  not  specifically 
implemented  in  7GM.  Instead,  their  functionality  is  included 
in  the  7GM  attributes  CHARPLANE,  CHARSIZE  and  CHARSPACE.  The 
text  string  orientation  is  defined  oy  the  CHARPLANE  (a 
vector  in  World  Coordinates  originating  at  tne  CP)  and  a 
"string  extent"  vector.  The  string  extent  vector  is  obtained 
from  the  CHARSPACE  and  CHARSIZE  attributes.  Figure  3 
illustrates  the  components  of  these  two  attributes. 


a  ■  CHARSIZE  x  component 

b  -  CHARSIZE  y  component 

c  =  CHARSPACE  dx  component 

d  =  CHARSPACE  dy  component 

Figure  3.  CHARSIZE  and  CHARSPACE  attribute  components 
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The  string  extent  is  the  result  of  multiplying  the  vector 
'V  by  the  number  of  characters.  *?*  originates  at  the  CP. 
The  boxes  containing  the  text  characters  will  be  in  the 
character  plane  with  their  lower  left  corner  on  the  string 
extent  vector.  A  wide  variety  of  directions  the  text  may 
follow  stems  from  the  fact  that  values  for  the  attribute 
components  can  be  positive  or  negative. 
7 .   Ill i b i 1 i t z 

In  CORE  tnere  is  a  segment  attribute  called 
VISIBILITY  which,  if  "on",  means  to  display  a  specified 
segment  on  the  output  device  and,  if  "off",  to  remove  it 
from  the  screen.  This  capability  also  exists  in  VGM  where  a 
segment  may  be  POSTed  to  mate  it  visible  or  UNPOSTed  to 
remove  it  from  the  picture. 

B.   CORE  FUNCTIONS  NOT  IMPLEMENTED  BT  VGM 

The  following  list  of  CORE  functions  are  not  implemented 
at  all  in  VGM: 

1.  pen   attribute 

2.  marfcer_symbol   attribute 

3.  picfc_id  attribute 

4.  naming   of   primitives 

5.  view_up  vector 

6.  some   inquiry   routines 

7.  terminate_,    disable_,   and   enable_group   routines 

8.  batch   update 
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9.  escape  mechanism 

10.  nighlighting 

11.  hierarchical  level  structure 

12.  acceptance  of  asynchronous  input 

C.     FUNCTIONS    IMPLEMENTED    BT   VGM   NOT    IN    CORE 
SPECIFICATION 

1 .  PliOlLt  i  ves 

The  following  primitives  have  been  added  to  VGM: 

a.  rectangle 

b.  arc 

c.  polygon 

d.  flood 

The  flood  primitive  is  for  use  with  bit  mapped, 
color  devices.  Flood  locates  the  CP  and  establishes  the 
smallest  area  surrounding  it  bounded  by  arcs  or  lines.  This 
area  is  then  filled  with  a  user  specified  color.  If  the  CP 
is  not  enclosed  then  it  is  possible  to  flood  the  entire 
display  surface. 

2 .  A  tt.r  ib  uie  s 

For  terminals  capable  of  color  graphics  7GM  adds  a 
BACKSR0UND_C0L0R  attribute  and  an  ADDITIVE_MODE  attribute. 
The  former  is  self  explanatory.  The  latter  determines  how  a 
declaration  of  any  new  color  attribute  is  to  be  treated.  If 
ADDITIVE_M0DE  is  "on"  then  the  bit  pattern  for  the  old  color 
is   logically  ORed  with  the  bit  pattern  for  the  new  color, 
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and  tne  resulting  pattern  becomes  tne  value  of  the 
attribute.  Otherwise  the  new  color  bit  pattern  simply 
replaces  the  old  one. 

4  BLINK  attribute  is  implemented  in  VGM,   wnicn  is 
intended   to   be  one  method  of  replacing   the  CORE  system 
HIGHLIGHTING  attribute  wnicn  has  been  left  out. 
3.   Oiher  ?£aiure.s 

In  VGM,  there  is  a  mechanism  for  modifying  a 
segment  after  it  has  been  closed.  This  is  the  EXTSEG  feature 
which  effectively  re-opens  the  segment  and  allows  additional 
graphical  information  to  be  appended  to  the  existing  file. 
The  feature  only  allows  addition  of  information  and  requires 
that  the  CLOSEG  command  be  issued  after  the  addition  is 
complete. 

If  a  graphics  device  that  is  currently  in  use  has 
both  input  and  output  capabilities,  VGM  will,  if  directed  by 
the  application  program,  "bacic  transform"  input  coordinates 
from  Physical  Device  Coordinates  to  World  Coordinates.  CORE 
will  only  bacfc  transform  to  Normalized  Device  Coordinates. 

VGM's  error  handling  and  debugging  aids  offer  more 
than  is  required  by  the  CORE  proposal.  In  VGM  the  user  has 
the  capability  to  specify  tne  maximum  tolerable  error 
severity  and  the  maiimum  tolerable  number  of  errors.  If 
either  maximum  is  exceeded,  the  program  will  terminate.  Wnen 
errors   are  detected,   an  entry  is  made  into  an  error   trace 
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file.  This  file  is  intended  to  be  a  debugging  tool.  It 
contains  the  error  code  number,  a  brief  description  of  tne 
error,  the  relevant  parameters  involved  in  tne  error,  tne 
name  of  tne  routine  in  which  tne  error  was  detected  and  tne 
result  of  tne  error  (corrected,  ignored,  default 
substitution  or  program  termination). 

An  option  tnat  SSPC  left  open  to  imp  ementors  was 
now  to  treat  non-graphical  data  sent  to  a  terminal  being 
used  for  CORE  graphical  output.  Typically,  tnis  mignt  be 
parent  language  I/O  in  the  form  of  write  statements  or  a 
system  message  to  the  particular  terminal.  In  VGli  there  is  a 
SET_POSITION  function  which  identifies  an  NDC  position 
specifying  where  non-grapnical  output  is  to  appear  on  tne 
screen.  This  output  is  affected  by  neither  attributes  nor 
the  CP. 

D.   EQUI7ALENT  FUNCTIONS  WITH  DIFFERENT  NAMES 

This   is   tne  simplest  category  of  differences   between 

CORE  and   VGM.   Below   is  a  short  list   showing  equivalent 

functions  in  CORE  and  7CM. 

CORE  name.  VGM  name 

charprecision  cnarquality 

detectabili  ty  picJcability 

highlighting  blinK 

world  coordinate  modelling  transformation 

transformation 
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71.   THE  7GM  DE7ICE  DRI7ER 

The  device  driver  is  the  connecting  linfc  between  7GM  and 
grapnics  nardware.  Its  purpose  is  to  tate  grapnical  data 
from  7GM  via  the  designated  COMMON  storage  area  and 
construct  an  instruction  in  a  format  compatible  with  the 
particular  device  it  is  written  for.  The  software  for  the 
device  driver  is  divided  into  6  modules. 

A.  THE  DE7ICE  CHARACTERISTICS  TABLE 

This  table  is  a  COMMON  blocfc  of  variables  describing  the 
characteristics  of  the  graphics  device  for  which  the  driver 
is  written.  It  is  implemented  as  a  BLOCK  DATA  source  program 
and  is  accessed  by  all  of  the  executable  modules  of  the 
driver.  It  is  initialized  wnen  the  module  is  compiled  and  is 
treated  as  "read  only"  by  all  of  the  routines  referencing 
it. 

B.  THE  STREAM  INFORMATION  TABLE 

This   is  anotner  COMMON  bloc*  of  data  which  holds  tne 

current  value  settings  for  attributes  for  each   stream.  The 

table  is  updated  by  tne  driver  routines  as  the  values  are 

changed.   Wnen  the  BLOCK  DATA  source  file  is   compiled,  tne 
default  attribute  values  are  set. 
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C.  THE  RUN  TIME  INFORMATION  TABLE 

This  table,  lifce  the  stream  information  table  is  subject 
to  continuous  update  by  the  device  driver  routines.  It 
contains  the  buffer  that  holds  the  instruction  to  be  sent  to 
the  graphics  device.  Pointers  required  for  Keeping  current 
positions  in  the  instruction  buffer  (CODBUF)  are  also  in  the 
run  time  information  table.  In  addition  there  are  variables 
for  the  identification  of  the  debug  file  and  several  nost 
computer  related  values. 

D.  ROUTINES  EXECUTING  VSM  PRIMITIVES  (OnLIBl) 

This  module  is  executable  code  that  is  intermediate 
between  7GM  and  the  device  instruction  creating  portion  of 
the  driver.  Its  routines  are  invoiced  from  7GM  and  it  in  turn 
calls  routines  to  create  the  appropriate  data  to  fill 
CODBUF.  OnLIBl  is  graphics  device  independent  but  is  nost 
machine  dependent.  Contained  in  OnLIBl  is  the  OnEIEC  routine 
that  is  tne  only  executable  code  in  tne  driver  software  that 
communicates  uith  7GM. 

E.  DEVICE  INDEPENDENT  LIBRART  OF  SHARABLE  ROUTINES  (SKELIB) 
This   collection  of   routines   is  a   set   of   device 

independent  operations  that  are  optionally  available  to 
OnLIBl.  These  routines  perform  operations  lifce  projection  on 
a  plane,  clipping,  image  transformations,  line  style 
generation  etc.  For  nighly  capable  devices  which  perform 
these  tasics  themselves  OnLIBl  would  not  reference  SKELIB  but 
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instead  cause  the  specific  device  instructions  to  be 
generated.  For  devices  that  lactc  some  of  these  features  in 
hardware,  SKSLIB  provides  software  simulation. 

F.   DEVICE   DEPENDENT  ROUTINES  GENERATING  INSTRUCTION  CODES 
(0nLIB2) 

This  set  of  subroutines  fills  the  instruction  buffer 
witn  instructions  and  data  specifically  formatted  for  tne 
target  device.  Each  byte  of  CODBUF  must  be  precisely  set  to 
be  compatible  with  the  graphics  device.  0nLIB2  builds  tne 
full  instruction  and,  when  complete,  causes  it  to  be  sent  to 
the  terminal.  The  communication  with  the  terminal  is  done 
with  MACRO  routine  QtfRITE  which  uses  the  host  computer's  I/O 
communication  facilities  and  treats  the  graphics  device  as 
an  I/O  port. 

All  of  the  device  drivers  share  tne  stream  information 
table  and  SKELIB.  Each  driver  installed  with  VGM  however 
must  contain  each  of  the  other  four  modules.  The  inter- 
connection of  the  various  device  driver  modules  is  snown  in 
Figure  4. 
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711.   RJS2LXS  AND  SUGGESTIONS  FOR  £OIURJ  STUDY 

A.   SOFTWARE 

As  stated  in  tne  Introduction,  tne  purpose  of  tnis 
research  was  to  lay  tne  groundwork  for  a  detailed  study  of 
the  CORE  graphics  system.  A  great  deal  of  progress  has  been 
made  in  this  effort.  Tne  VGM  implementation  of  tne  CORE 
system  is  installed  at  the  Naval  Postgraduate  School  and  is 
capable  of  operating  with  the  Tettronix  4014  storage  tube 
display  terminal.  The  system  has  passed  the  initial  stages 
of  testing.  Additionally,  algorithms  nave  teen  developed  and 
Implemented  on  a  limited  basis  for  expanding  the  VGM 
software  to  interface  with  tne  Ramtefc  RM-9400  graphics 
system.  These  portions  of  the  project  are  discussed  in 
detail  in  Appendices  A  and  B  respectively. 

A  less  tangible,  but  equally  valuable  result  of  this 
study  is  the  experience  and  insight  gained  with  both  CORE 
and  the  7GM  implementation.  Appendix  C  is  one  product  of 
this  new  Knowledge.  It  is  a  brief  tutorial  on  programming 
with  VGM  and  is  written  specifically  for  the  Naval 
Postgraduate  School  installation.  The  tutorial  is  not 
intended  to  replace  the  Bell  Northern  Research  User's 
Manuals.  It  is  meant  to  be  used  in  conjunction  with  them  and 
deliberately  avoids  details  which  can  easily  be  found  by 
referencing  them. 
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B.   CORE  EVALUATION 

The  CORE  system  is  currently  only  a  proposal  and  as  such 
it  is  intended  for  thorough  scrutiny  by  tfte  graphics 
community.  In  researching  tnis  subject  a  number  of  issues 
have  been  identified  which  may  provide  a  frameworfc  for  an 
evaluation  of  tne  system.  This  collection  does  not  purport 
to  be  einaustive  but  is  presented  to  provide  a  base  for 
future  worlc. 

The  prime  issue  to  be  evaluated  is  that  of  program 
portability.  Tnis  has  already  been  discussed  in  depth  in  the 
GSPC  proposal  and  summarized  in  this  report  in  Chapter  III. 
In  the  course  of  this  study  some  different  perspectives  on 
the  problem  have  come  to  light.  It  appears  that  there  might 
be  hierarchical  levels  of  portability  other  tnan  tnose 
listed  in  the  3SPC  report.  Graphics  devices,  computing 
systems,  operating  systems  and  CORE  Implementations  are  all 
variables  in  this  area.  Another  way  of  classifying  the 
portability  of  a  program  might  be  in  terms  of  these 
environmental  factors.  For  example,  some  programs  may  be 
portable  from  one  device  to  another  as  long  as  the  computing 
environment  is  not  changed.  Others  may  survive  a  change  of 
computing  machinery  provided  the  operating  systems  are  the 
same.  Conversely,  changing  operating  systems  rather  than 
computers   might   be   the  defeating  factor   in  a   program's 
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portability.  Tet  another  possibility  is  that  different 
implementations  of  CORE  may  be  tne  reason  for  changes  in  a 
given  program. 

It  would  be  difficult  to  develop  furtner  tne  portability 
issue  from  this  point  of  view  until  a  variety  of 
environments  exist  for  side  by  side  comparisons.  The 
presentation  of  this  perspective  is  recorded  here  so  tnat 
when  such  facilities  are  available  its  validity  can  be 
considered. 

To  *ain  widespread  acceptance  the  CORE  system  must 
be  easy  to  implement.  Criteria  are  needed  to  measure  the 
difficulty  of  implementation.  The  following  list  presents 
questions  whicn  may  serve  as  possible  evaluation  mecnanisms 
for  this: 

a.  Can  the  Implementation  be  reduced  to  simply 
following  some  kind  of  implementation 
"algorithm"? 

b.  Does    the   design   of    the   implementation 
favor  one  type  of  device  over  another? 

c.  Does    the   design   of    the   implementation 
favor  one  computing  environment  (eitner  nardware 
or  operating  system)  over  another? 

d.  What  tradeoffs  in  portability  have  to  be  made  so 
that  implementation  can  be  facilitated? 


56 


3-   Device  Capability. 

As  is  true  of  almost  all  standards  in  tne  computing 
industry  the  CORE  system  does  not  tafce  full  advantage  of  tne 
hardware  capability  of  many  installations.  It  was  never 
intended  to  meet  all  possible  needs.  Nonetheless  a  means  of 
assessing  the  loss  in  device  capability  under  tne  CORE 
system  should  be  established.  A  guideline  for  determining 
when  the  gains  from  using  CORE  are  outweigned  by  the  losses 
from  not  utilizing  the  full  power  of  the  device  would  be  a 
highly  desirable  tool,  particularly  for  facilities 
generating  a  wide  range  of  graphics  applications  programs. 

4.   CORE  Capability. 

Perhaps  the  most  difficult  and  controversial 
question  in  the  evaluation  of  CORE  is  whether  its 
capabilities  really  are  sufficient  for  most  grapnics 
programmers.  Further,  how  adaptable  to  future  needs  will  the 
system  be?  Is  hardware  technology  llicely  to  progress  to  a 
point  where  CORE  is  no  longer  adequate  as  a  standard?  Is  it 
liJtely  that  computer  grapnics  will  expand  into  areas  that 
CORE  was  never  intended  to  serve?  Certainly  none  of  these 
issues  will  be  resolved  easily.  Each  question  in  itself 
could  be  a  topic  for  detailed  analysis.  They  are  presented 
here  Just  to  suggest  areas  for  further  study. 
C.  OUTLINE  OF  CONTINUING  DEVELOPMENT  OF  THE  NPS  SYSTEM 

In   the  course   of   this  study   some   ideas  have   been 
formulated   for  a  methodology  to  direct  continuing  worK   on 
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the  project.   This  is  only  one  worker's  point  of  view  and  It 
should  serve  as  a  guide  rather  than  an  absolute  to  follow-on 
workers. 
1.  VGM 

Tne  first  order  of  business  snould  be  to  modify  tne 
Bell  Northern  Research  test  routine,  AKPAK,  so  that  the  full 
range  of  VGM  functionality  can  be  verified.  This  would 
entail  construction  of  appropriate  overlays  for  tne  test 
pacfcage  so  that  the  large  amount  of  object  code  can  be 
accomodated  on  tne  limited  PDP-11/50  memory.   Once  this   is 

accomplished,  AKPAK  can  serve  as  a  benchmark  program  for 
testing  additional  drivers  that  are  added  to  VGM.  CTsing 
AIPAE  as  a  benchmark  should  also  aid  in  studying  other 
portability  issues. 

2  •   5SIi£?.  Slivers 

The  pattern  for  writing  tne  code  tnat  interfaces  tne 
device  independent  portion  of  a  software  driver  and  the  RM- 
9400  has  been  established.  Furtner,  it  has  been  partially 
implemented  and  tested.  The  next  step  is  to  complete  the 
remaining  subroutines  in  tne  04LIB2  (device  dependent 
routines)  module  according  to  tne  algorithms  provided  in 
Appendix  B.  Once  a  new  04LIB2  has  been  built  it  can  be 
incorporated  into  VGM  and  tested,  first  as  a  separate  entity 
using  the  provided  DDTEST  program  and  then  as  a  fully 
integrated  part  of  VGM  usin*  AKPAK. 
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By  no  means  would  tnis  complete  worn:  on  tne  Ramtet 
driver.  After  tne  04LIB2  worfc  is  completed  tne  driver  would 
still  fall  far  snort  of  taking  full  advantage  of  tne  power 
of  the  RM-9400.  A  topic  of  study  all  its  own  would  be  the 
modification  of  tne  "device-independent"  sections  of  tne 
driver  code  to  put  tne  sophisticated  features  of  tne  RM-9400 
into  use. 

An  ancillary  project  would  be  to  develop  yet  another 
driver  for  a  new  graphics  device.  The  object  of  this  study 
would  not  be  to  merely  expand  the  capabilities  of  the 
existing  VGM  system.  What  it  is  hoped  would  emerge  from  such 
research  is  a  pattern  for  writing  device  drivers.  Such  a 
formula,  if  it  exists,  would  be  a  very  useful  tool  for 
further  expansion  of  VGM  without  the  necessity  of  re- 
learning  already  established  techniques. 
3 .   P or t a b ili ly 

With  a  fully  operational  VGM  system  and  a  variety  of 
devices  available  for  use,  portability  testing  can  begin. 
The  suggestion  is  to  direct  the  work  along  lines  mentioned 
earlier  in  this  chapter  in  section  B.  After  varying  the 
graphics  devices  and  studying  the  system  behavior  over  a 
variety  of  them,  worfc  should  proceed  to  studying  program 
behavior  under  changes  in  the  computing  environment.  Otner 
operating  systems,  other  computers,  and  other  COEE 
implementations  are  available  for   such   research.   This 
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variety  of  environments  in  a  single  location  would  provide 
an  excellent  test  bed  for  tnorougn  evaluation  of  tne  CORE 
standard. 
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APPENDIX   A.    IMPLEMENTATION   OF  ?GM  AT  NAVAL   POSTGRADUATE 

SCHOOL 

The  aim  of  this  portion  of  the  project  was  to  gain 
insight  into  the  operation  of  VGM  and  to  install  a  wonting 
version  of  it  on  the  Naval  Postgraduate  Scnool's  graphics 
facility.  Bell  Northern  Research  (BNR)  of  Ottawa,  Canada 
supplied  the  school  with  a  tape  containing  tne  source  code 
for  v*GM,  version  1.1.  and  two  device  drivers.  One  driver  was 
written  for  a  Chromatics  color  graphics,  raster  scan 
terminal  and  the  other  for  a  Tefctronix  401X  storage  tube 
terminal.  A  Teictronix  4014  was  readily  available  at  Naval 
Postgraduate  School  and,  being  a  simpler  device,  was  deemed 
the  best  choice  for  installing  and  testing  VGM. 

On  the  same  tape  as  the  VGM  and  device  driver  software 
were  several  command  files  to  aid  in  installing  the  system. 
These  command  files  did  such  things  as  compile  the  source 
modules,  install  libraries  and  build  tasks.  Their  inclusion 
was  intended  to  save  some  user  time  and  effort  and  to  help 
avoid  erroneous  or  incomplete  system  commands  that  might 
arise  during  any  of  the  initial  stages  of  software 
installation. 

The  plan  for  implementation  was  the  following: 
A.   Compile  all  of  the  source  modules  making  up  VGM. 
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B.  Convert  the  VGM  object  code  into  a  FORTRAN  library  under 
RSX. 

C.  Compile  all  of  the  source  modules  mating  up  the  Tefrtronix 
device  driver. 

D.  Lin*  the  object  code  from  tne  device  driver  compilations 
into  a  single  tasfc  called  02DRIV. 

E.  Test   the   driver  separately  from  YGM  by  using   a   test 
routine  supplied  by  Bell  Northern  Research. 

F.  Install   02DRIV  under  RSX  as   a   taste  available   for 
concurrent  use. 

3-.  Test  VGM  itself  using  the  Bell  Northern  Research  supplied 
test  graphics  program  AIPA5. 

Before  any  of  the  installation  could  begin,  tne  software 
on  the  tape  had  to  be  made  easily  accessible.  This  was  done 
by  copying  it  onto  the  RSX  on-line  disfc  storage.  A  copy  of 
the  BNR  software  may  be  found  under  directory  DP0: [201 ,211] . 
This  copy  of  the  source  code  is  intended  to  remain  unedited. 
Any  changes  to  the  code  during  7GM  installation  were  made  by 
transferring  original  copies  to  a  worfcing  directory  and 
editing  there.  To  generate  object  code  the  modules  necessary 
for  ?GM  and  the  device  driver  compilation  were  PIPed  to 
directory  DP3:  [201,210] .  Once  the  source  code  was  available, 
the  command  file  VGMCOM.CMD  was  executed.  VGMCOM.CMD  nad  to 
be  modified  somewhat  to  mate  it  compatible  with  tne  F4P 
compiler.  The  BNR  software  was  written  under  an  older  PCP 


62 


version  of  FORTRAN  so  tne  compiler  commands  had  to  be 
adjusted  accordingly. 

In  all,  VGM  contains  12  output  modules  and  7  input 
modules.  Each  module  is,  in  turn,  made  up  of  several 
subroutines  grouped  by  tne  particular  function  tbey  perform. 
For  example,  the  output  module  INISTR  (INltialize  STRing  — 
named  for  the  first  of  tne  component  subroutines)  contains 
16  separate  subroutines  all  naving  to  do  with  eitner  stream 
or  segment  manipulations.  There  are  also  two  blocfc  data 
modules  and  a  test  program. 

Once  object  code  was  generated  for  all  of  tne  VGM 
routines,  command  file  7SMLIB.CMD  was  executed  under  tne  RSX 
LIBRARY  utility,  creating  a  library  of  all  tne  executable 
routines  concerned  with  input  and  output. 

The  compilation  process  was  repeated  for  the  source  code 
modules  for  the  Tefctronix  driver.  Command  file  02DC0M.CMD 
accomplished  this.  The  device  driver  modules  consist  of  two 
"libraries"  which  manipulate  the  device  independent 
information  coming  from  7GM.  A  third  library,  02LIB2,  does 
the  actual  creation  of  instructions  to  the  TeKtronix.  02LIB2 
is  the  portion  of  the  device  driver  that  linics  VGM  and  the 
terminal.  There  are  also  some  blocfc  data  modules  which  set 
up  communication  areas  between  the  device  driver  and  VGM  and 
also  provide  specific  device  parameters  where  needed  to  both 
7GM  and  the  device-independent  portions  of  the  driver.  Two 
MACRO  modules   are   included  to   handle   input   and   output 
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communication  between  the  device  and  the  operating  system. 
The  rest  of  the  driver  related  modules  concern  themselves 
with  interfacing  the  device  independent  parts  of  the  driver 
and  VGM  itself. 

Like  VGM,  the  object  code  for  the  device  driver  modules 
are  built  into  a  library  under  RSX  by  file  02DLIB.CMD.  This 
library  however  is  only  a  temporary  holding  area  for  the 
driver  object  code.  It  is  referenced  by  the  file  02DRIV.CMD 
and  the  object  modules  are  linked  together  into  a  single 
tasit  called  02DRIV. 

With  VGM  existing  as  an  object  library  and  02DRIV  as  an 
individual  task  the  preliminary  work  is  done.  Testing  is 
accomplished  in  two  stages.  The  first  is  testing  the 
functionality  of  the  device  driver  Independent  of  VGM.  The 
test  program,  02TEST,  was  provided  by  Bell  Northern  Research 
and  was  compiled  with  the  rest  of  the  driver  routines  and 
block  data  programs.  The  file  02TEST.CMD  Units  the  test 
proeram,  the  driver  library,  and  the  block  data  into  a 
single  executable  task  called  TEKTEST.  TEKTEST  exercises  the 
driver's  functionality  fully  and  is  available  for  use  in 
directory  DP3: [201,210]  . 

After  the  driver  was  satisfactorily  tested  alone,  the 
task  02DRIY  was  INSTALLed  under  RSX.  The  INSTALL  feature  is 
an  RSX  utility  that  activates  a  specified  task  and  mates  it 
available  for  invocation  from  another  active  task. 
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The  next  step  is  building  the  VGM  test  tasfc.  The  test 
routine,  AKPAK,  is  also  supplied  by  BNR  and  is  intended  to 
thoroughly  test  VGM  and  any  selected  device  driver.  The 
command  file  provided  to  build  the  AKPAK  tas*  is  VGMTKB.CMD. 
The  initial  attempts  to  build  the  test  program  resulted  in  a 
Tasfc  Builder  diagnostic  indicating  that  not  enougn 
contiguous  disfc  space  was  available  for  the  AXPAK  task.  This 
was  partly  a  result  of  the  fact  that  AKPAK  and  tne 
associated  VGM  library  routines  require  a  very  large  bloclc 
of  disic  storage.  This  is  also  indicative  of  another 
potential  problem.  Since  the  AKPAK  test  is  such  a  large  one 
it  is  not  lively  to  fit  into  the  available  core  memory.  It 
will  most  lively  require  construction  of  overlays  to  run  on 
the  limited  memory  resources  of  the  PDP-11/50  at  NPS . 

It  was  decided  that  at  least  for  the  initial  phase  of 
study  to  follow  a  somewhat  shorter  and  simpler  testing  path. 
Rather  than  become  involved  in  constructing  overlays  and 
possible  changes  in  the  structure  of  AKPAI,  a  more  limited 
test  program  would  be  written.  Since  one  goal  of  this  part 
of  the  worn  was  to  get  an  operational  VGM  system  it  was 
decided  to  at  least  ensure  the  proper  interfacing  between 
the  user  program,  VGM  and  02DRIV. 

Toward  this  end,  a  much  simplified  test  program  was 
written,  called  VGMTST.  It  was  linked  witn  VGM  and  tne 
necessary  bloc*  data  routines  by  file  7TST.CMD.  VGMTST 
exercised  several  of  the  2-dimensional   drawing,   move,   and 
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marker  primitives,  the  low  quality  text  capability  and  the 
SBT_POSITION  feature.  In  addition,  some  of  tne  device  and 
segment  control  functions  were  also  tested  since  their  use 
is  essential  for  any  VGM  operation. 

The  execution  of  VGMTST  was  quite  successful.  Tne 
drawings  on  the  Tetxronix  screen  appeared  as  expected.  The 
tasit  is  available  for  use  under  directory  DP3:  [201 ,210]  .  To 
use  tne  test  routine,  turn  on  the  TeKtronix  4014  and  log  in 
under  RSI  by  the  standard  procedure.  Enter  the  proper 
directory  by  typing 

SET  /UIC  =  [201,210] 
after  the  RSI  prompt  (  >  ).   Next,   wnen  tne  prompt   appears 
issue  the  commands 

>INS  02DRIV 

>RUN  VGMTST 
The   test   program  will  execute  and  tne  resultant   grapnics 
will  appear  on  the  screen. 
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APPENDIX  B.    CONSTRUCTION  QF  A  DEVICE  DRIVER  FOR  THE  RAMTEK 

RM-9400 

A.  DEVICE  DRIVERS 

Bell  Northern  Research's  device  drivers  are  identified 
by  unique  integer  designations,  the  particular  integer  being 
incorporated  into  tne  driver  name  and  the  names  of  tne 
modules  that  comprise  them.  The  modules,  and  subroutines  in 
them,  specific  to  the  Chromatics  driver  all  begin  with  an 
01-  identifier,  for  example,  01LIB2  or  01M0VE.  The  Tefctronix 
4014  software  is  device  driver  #2 ,  tnus  its  names  are  all 
prefixed  with  an  02-.  Also  provided  is  a  driver  which  shares 
the  Tefctronix  4014  code  but  is  to  be  used  with  the  Tefctronix 
4010.  This  uses  the  03-  prefix.  Only  the  03EXEC  (the 
interface  with  tne  VGM  software)  routine  has  tne  prefix,  the 
rest  of  the  driver  uses  the  Tefctronix  4014  code.  For  the 
routines  to  be  written  as  part  of  this  study,  tne  04-  prefix 
was  selected,  being  the  next  in  the  sequence. 

The  target  device  in  this  portion  of  the  study  was  the 
Ramtefc  RM-9400,  a  very  powerful  and  sopnistlcated  color 
raster  scan  graphics  device.  Adaptation  of  a  similar  driver 
seemed  tne  best  course  of  action.  The  Chromatics  grapnics 
terminal  is  also  a  color,  raster  device  though  not  nearly  as 
advanced  as  the  RM-9400.  Nonetheless  its  driver  is  readily 
available   and  is  already  adapted   to   the   PDP-11/RSX 
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environment.  It  provides  a  good  starting  point  for 
developing  tne  Ramtet  software. 

The  initial  intent  in  tne  construction  of  a  device 
driver  for  tne  RM-9400  was  to  leave  tne  Chromatics  driver 
intact  as  far  as  possible.  Tne  module  SKELI3,  vnich  contains 
the  device  independent  hardware  feature  simulation  routines, 
was  left  unchanged.  The  Stream  Characteristics  Table  had  to 
be  modified  only  slightly  to  include  the  new  device.  The  Run 
Time  Information  Table  for  the  Ramtet  is  simply  a  copy  of 
the  one  provided  for  the  Chromatics  driver.  The  same  is  true 
for  04LIB1  with  the  exception  of  tne  04EXEC  routine. 
Modifications  to  04EXEC  were  very  slight.  Inclusion  of  the 
new  04EXEC  routine  did  necessitate  changes  to  tne  VGM 
software  in  the  INISTR  and  SELSTR  (SELect  STRing)  modules. 

The  bulfc  of  the  worfc  in  writing  the  new  driver  will  be 
in  developing  a  new  04LIB2.  Creation  of  a  new  Device 
Characteristics  Table  is  also  important.  The  latter  requires 
an  item  by  item  reviewing  of  tne  table  variables  and 
providing  the  appropriate  values  as  they  pertain  to  the  RM- 
9400.  Details  of  what  entries  should  be  made  are  in  the  BNR 
"Skeleton  Driver  Installation  Manual".  In  this  study  very 
little  of  the  RM-9400's  capabilities  were  exercised  and  the 
importance  of  the  Device  Characteristics  Table  was  secondary 
to  getting  a  rudimentary  system  in  operation.  As  the  device 
driver  develops  into  a  more  refined  form  and  incorporates 
more    of   the   RM-9400's   capabilities,     tne   Device 
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Characteristics   Table   should   be   reviewed  and   updated 
continuously. 

B.   RAMTEK  RM-9400  INSTRUCTION  FORMAT 

Before  writing  any  of  tne  routinest  a  Knowledge  of  the 
format  of  an  RM-9400  instruction  is  required.  Tne  RM-9400 
instruction  is  a  variable  length  buffer  of  16  bit  words.  The 
first  8  bits  of  the  first  word  contain  tne  code  for  the 
function  the  device  is  to  execute.  For  exa  pie,  an  operation 
code  of  06H  (Ramtelc  mnemonic  INIT)  initializes  the  device;  a 
code  of  35H  (Write  Vector,  Unlinked  —  mnemonic  WVTT)  is  a 
line  drawing  instruction.  Tne  operation  code  determines  how 
much  more  of  the  instruction  buffer  the  RM-9400  needs.  For  a 
very  simple  instruction  like  INIT,  once  the  operation  code 
is  read,  the  rest  of  the  buffer  is  ignored.  For  something 
like  a  line  drawing,  However,  the  device  will  require  a 
number  of  extra  words  of  information  before  it  can  execute 
the  instruction.  The  extra  words  will,  as  a  minimum,  have 
to  indicate  the  end  points  of  the  line,  and  may  include  the 
foreground  and  background  colors  as  well  as  the  line  style 
and  thickness.  Depending  on  the  operation,  some  of  the 
additional  instruction  words  are  essential  and  some  are 
optional.  In  most  cases,  if  a  piece  of  data  is  required  and 
is  not  specified,  a  default  value  will  be  used.  The 
architecture  of  the  RM-9400  is  sucn  that  it  is  possible  for 
the  user  to  specify  the  default  parameters  values. 
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The  presence   of   additional  words   of   information   is 

Indicated  to  tne  Ramtefc  by  flag  bits.  Tne  last  8  bits  of  tne 

first  word  are  the  primary  set  of  flags.  Only  three  of  these 

are  involved  in  extending  the  size  of  the   instruction.   The 

five  high  order  bits  of  the  low  byte  modify  the  execution  of 

the  operation  code  as  indicated  in  the  following  table. 

bits  6  <&  7       code  for  tne  mode  of  addressing 

refresh  memory 

bit   5  selects   additive   mode   of 

text  output 

bit  4  reverses  foreground  and 

background  colors 

bit  3  sets  device   to  process 

bytes  in  a  word  in  reverse  order 

It    is   the   tnree   lowest   bits   that   indicate   how   many 

additional  words  of  data  will  be  in  tne  instruction.   Bits  2 

and  1  each  indicate  whether  a  particular  "operand  flag  word" 

will  be  in  the  instruction  buffer. 

If  bit  1  in  set,  "operand  flag  word  #l"  (OF1)  will 
immediately  follow  tbe  word  containing  the  operation  code 
and  the  primary  flags.  0F1  is  another  set  of  flags  each  of 
which  corresponds  to  additional  pieces  of  information  in  the 
instruction.  The  setting  of  one  of  the  16  bits  in  OF1  means 
that  one  or  more  words  of  data  will  follow.  The  order  of  the 
additional  data  will  correspond  to  the  bits  of  OF1 ,  from 
lowest  to  highest. 

A  sample  bit  pattern  might  be 

0000  0001  0000  0010  (0102H) 
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This  would  indicate  that  two  additional  pieces  of  data  (one 
for  each  "l"  bit)  are  in  the  Instruction  buffer  following 
OF1.  In  this  case  the  two  bits  that  are  set  mean  tnat 
"foreground"  data  and  "line  dimension"  data  are  present 
(bits  1  and  8  respectively).  Tne  foreground  information  is 
simply  an  integer  index  to  a  color  table  in  Ramtefc  refresh 
memory  and  only  requires  a  single  word  of  storage.  Tne  line 
dimensioning  information  is  more  complex  consisting  of  a 
pattern  code  and  a  repeat  code  (interpretation   of   tnese 

codes  is  not  important  to  the  current  discussion)  and 
requires  two  words.  These  two  words  will  follow  tne 
foreground  word  in  the  buffer.  The  code  that  the  RM-9400 
would  execute  is  shown  symbolically  in  Figure  5. 


bit  15  bit  0 


op  code 

i          _  i 

flags 

operand  fla« 

■  word  1 

!  foreground  color  index 

!    line"  code 

word  1 

line  code 

word  2 

Figure   5.    Instruction  Buffer  with  0F1   and  Associated 

Parameters 

Bit   2   of  the  primary  flags  indicates  the   presence   or 
absence  of  "operand  flag  word  2"  (0F2).  If  flag  bit  2  is  set 
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then  0F2  will  immediately  follow  OF1.  If  flag  bit  2  is  set 
and  flag  bit  1  is  not,  tnen  tne  word  immediately  following 
the  operation  code  word  is  0F2.  0F2  performs  exactly  tne 
same  tasic  as  OF1  except  that  only  its  six  least  significant 
bits  are  used. 

Flag  bit  0  in  the  operation  code  word  indicates  that 
text  or  numeric  data  will  follow  0F1,  0F2  and  their 
associated  parameters  if  present.  The  first  word  of  this 
data  will  always  be  an  integer  indicating  now  many 
additional  bj£t£S  of  data  will  come  after  it. 

To  illustrate,  suppose  the  user  wants  to  draw  a  line 
from  the  pixel  at  screen  coordinates  100,100  to  the  one  at 
500,500.  He  further  want  its  color  to  be  tnat  of  #4  in  the 
color  table  in  refresh  memory  and  his  line  dimension  code  is 
given  by  the  words  0101H  and  0003H.  The  instruction  buffer 
would  be  that  shown  in  figure  6. 

To  a  rough  approximation  the  operation  codes  for  RM-9400 
instructions  correspond  to  VGM  primitive  and  device  control 
functions.  Similarly,  the  parameters  referenced  by  the 
operand  flag  words  correspond  to  attribute  values.  While 
this  is  not  always  the  case  it  provides  a  good  rule  of  thumb 
for  the  initial  development  of  a  device  driver.  Those  VGM 
calls  executing  a  primitive  or  control  function  will  cause 
an  operation  code  to  be  placed  in  the  instruction  buffer. 
Those  setting  an  attribute  will  cause  the  setting  of  flags 
and  loading  of  appropriate  parameter  values. 
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C.   SETTING  ATTRIBUTES 

1  •   Storage  Requirements. 

Vnen  an  attribute  is  set  it  does  not  necessarily 
have  to  tafre  effect  immediately.  Therefore  memory  locations 
must  be  available  to  store  tne  values  of  attribute  settings 
until   an  appropriate  operation  code  using  them  is   loaded 


opcode 
0011  0101 


flags 
0000  0011 


0F1 
0000  0001  0000  0010 


color  table  index 
0000  0000  0000  0100 


line  code  word  1 
0000  0001  0000  0001 


line  code  word  2 
0000  0000  0000  0011 


data  length  word 

0000  0000  0000  1000 


x  start  coordinate 
0000  0000  0110  0100 


y  start  coordinate 
0000  0000  0110  0100 


x  end  coordinate 

0000  0001  mi  0100 


y  end  coordinate 
0000  0001  mi  0100 


Figure  6.   Instruction  buffer  for  line  with  specified   color 

and  style 
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into  the  instruction  buffer.  Tne  RM-9400  nas  tne  capacity 
for  setting  22  different  parameters,  eacn  one  corresponding 
to  a  bit  in  one  of  tne  operand  flag  words  (16  in  Oil  and  6 
in  0F2).  Not  all  of  the  parameters  that  are  entered  into  tne 
Ramte*  instruction  are  limited  to  a  single  word.  Although 
some  parameters  do  require  only  one  word  there  are  others 
that  need  2  or  4,  and  in  one  case  12,  words  of  storage.  The 
total  storage  required  for  tne  22  parameter  settings  is  47 
words.  A  Global,  integer  array  of  47  elements  named  PARAM  is 
set  up  as  part  of  a  BLOCK  DATA  program  to  store  these  values 
as  they  are  set.  Two  additional  "read  only"  arrays  are  also 
part  of  that  BLOCK  DATA  subroutine.  These  aid  in  referencing 
the  PARAM  array.  Integer  array  PRMPTR  of  length  22  contains 
indices  to  the  starting  location  in  PARAM  wnere  a  particular 
parameter's  values  are  saved.  Each  entry  in  PRMPTR 
corresponds  to  a  flag  in  one  of  the  operand  flag  words. 
Elements  1  through  16  of  PRMPTR  contain  pointers  to  the  lata 
associated  with  bits  0  tnrougn  15  of  0F1.  Elements  17 
through  22  do  the  same  for  bits  0  through  5  of  0F2.  The 
second  array,  PRMSIZ,  is  a  parallel  array  to  PRMPTR.  Each  of 
its  integer  values  is  the  size,  in  words,  of  the  particular 
parameter  pointed  to  by  the  corresponding  element  in  PRMPTR. 
The  values  of  PRMPTR  and  PRMSIZ  are  fixed  at  compile  time 
and  remain  unchanged  throughout  the  program.  PARAM  is 
initially  set  to  all  zero  entries  and  gets  updated  as  the 
various  attribute  values  are  assigned. 
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There  are  also  two  logical  arrays  and  three  logical 
variables  involved  in  keeping  track  of  attribute  settings. 
The  elements  of  the  logical  arrays  correspond  to  tne  bits  of 
0F1  and  0F2.  They  are  named  0F1AR3  and  0F2ARR.  If  a  bit  in 
either  0F1  or  0F2  is  to  be  set  by  a  particular  subroutine 
call  then  the  element  in  OF1ARR  or  0F2ARR  tnat  corresponds 
will  have  a  FORTRAN  value  of  .TRUE..  The  logical  variables 
correspond  to  the  lowest  three  bits  of  the  primary  flag  set 
of  the  Ramtek  instruction  operation  code  word.  For  bit  2 
there  is  0F2FLf  for  bit  1  there  is  OF1FL  and  for  bit  0  there 
is  DFFL.  All  of  the  logical  variables,  including  the  arrays 
are  initialized  to  .FALSE.. 

Finally,   the  three  words  wnich  actually  control  the 
instruction   buffer  size  must  be  kept:   0F1,   0F2,   and   DLW 
(data  length  word).   These  are  declared  as  integer  variables 
in  the  BLOCK  DATA  subroutine  and  initialized  to  zero. 
2  •   Isll!i§  S  to  rage  Operations 

When  a  subroutine  that  sets  an  attribute  is  called, 
several  operations  must  take  place,  not  necessarily  in  any 
particular  order.  One  of  the  required  events  is  that  the 
attribute  values  must  be  entered  into  the  proper  location  in 
PARAM.  This  is  done  in  a  special  subroutine  called  04L0AD. 
Its  essential  part  is  a  DO  loop  wnich  fills  the  array 
starting  at  the  location  indicated  by  an  element  of  PRMPTR 
and  filling  the  number  of  words  indicated  by  the 
corresponding  PRMSIZ  value.  Along  with  setting  the  parameter 
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values  a  flag  marfcing  the  fact  that  they  are  to  be  used 
must  also  be  set  In  either  0F1ARR  or  0F2ARR.  Also,  tne  flag 
indicating  either  071  or  0F2,  must  be  set,  so  either  0F1FL 
or  0F2FL  becomes  .TRUE.. 

Tne   code  for  any  subroutine  that  sets  an   attribute 
can  be  written  according  to  the  following  algorithm: 

input:  parameter  values 
begin  attribute  setting  subroutine 
set  0F1FL  or  0F2F1 

if  flag  in  0F1ARR  or  0F2ARR  not  set  then 
set  0F1ARR  or  0F2ARR  flag 

set  flag  in  0F1  or  0F2  by  adding  proper  power  of 
two 
end  if 

store  parameter  values  in  PARAM 
end 

Two   subroutines   have   been  written  that   carry   out   this 

process.   They   are  04C0LR  and  04BC0L.   The  source  code   for 

them   is   found  under  RSI  on   the   PDP-11/50   in  directory 

DP3:[301,lJ.   The   subroutine   04L0AD  is  also  found  in   tnis 

directory. 

3.   ZiiliUS  I^§  Instruction  Buffer 

The  critical  subroutine  in  module  04LI32  is   COPCOD. 

This   is   the  one   that   controls   the  filling  of   the 

instruction.   It   is   invoiced  by  the  primitive   and   control 

subroutines  in  04LIB2.  The  routines  that  call  COPCOD  pass  as 

a   parameter  an   index  to  an  array  containing   the   Ramefc 

operation  codes.   These  operation  codes  are  set   into   the 

array  OPCODE  at  compile  time.   They  are  designed  to  be   the 

Ramtefc  equivalent  of  the  intended  VGM  function.   COPCOD  gets 
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the   actual  code  from  the  array  OPCODE.   The  operation   code 

and  the  primary  flags  are  then  combined  into  the  first   word 

of   the  instruction  buffer.   COPCOD  also  causes  the   operand 

flagwords  (Oil  and  0F2),  their  parameter  values  and  the  data 

length   word  to  be  loaded  if  any  of  them  are   required.   The 

text   or  numeric  data  is  loaded  by  the  primitive  or   control 

routine  itself. 

The   following  algorithm  shows   the   operation   of 

COPCOD.  The  code  can  be  found  in  directory  DP3: [301,1]: 

input:  OPCODE  index 
begin  COPCOD 

get  actual  operation  code  from  array  OPCODE 

if  0F1FL  =  true  then  set  flag  bit  1 

if  0F2FL  ~   true  then  set  flag  bit  2 

shift   operation   code   to   upper   byte   of   first 
instruction  word  (multiply  by  256) 

add  flagword  to  shifted  operation  code 

load  operation  code  word  into  buffer 

load  0F1  and/or  0F2  as  indicated  by  flags 

load  parameters  in  proper  order  from  PARAM 

load  data  length  word  if  necessary 
end 

As  with  attribute  setting,  all  subroutines  wnich  are 

primitive   functions   can   be   patterned   after  a   single 

algorithm.   Control   functions  can  follow  this  same   pattern 

though   they   typically  will  not  require  data  values   to   be 

placed  in  the  instruction  buffer.  The  algorithm  is: 

input  data  values 

begin  function  execution 

set  D5TL  (lata  flag)  if  appropriate 

set  bit  0  of  fla«?s 

set  data  length  word  (DLW)  to  number  of  bytes  of  data 

call  COPCOD  —  pass  OPCODE  index 

load  data  values 

execute  instruction 
end 


77 


A  number  of  routines  nave  been  written  following 
tnis  algorithm.  They  include: 

04D0T       place  a  point  at  specified  coordinates 
04M0VE      cnange  current  cursor  position 
04DRAW      draw  a  line  between  two  specified  points 
04SSTR      output  a  text  string 
04RSET      erase  toe  screen. 
All   can   be  found  in  directory  DP3:  [301,1] .   It   snould   be 
noted   that  the  routine  04STR,   which  builds  an   instruction 
for  text  output,   inserts  an  extra  step  Before  loading  the 
data.   04STR  receives  its  text  data  in  an  integer  array  with 
one  alphanumeric  character  per  element.   The  RamteK:  requires 
textual  data   output  to  be  formatted  to  one   character   per 
byte.   Therefore  04STR  must   ma*e  this   conversion   before 
loading  the  data  into  the  buffer. 
4= .   Tes  t  ing 

As  the  routines  were  developed  tney  were  tested  for 
operability.  The  testing  was  at  a  very  low  level  simply 
checking  that  the  instruction  buffer  was  being  properly 
constructed  and  transmitted  to  the  RM-9400.  All  of  the 
routines  developed  in  this  portion  of  the  study  nave  been 
successfully  checfced  in  this  manner.  The  test  programs  are 
modularized,  each  being  called  by  a  master  routine  called 
DUMTST.  The  individual  test  routines  are  named  LINTST  (LINe 
drawing   TeST) ,   PTTST  (FoinT  placement  TeST),   TITST   (TeZt 
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output  TeST)  and  COLTST  (COLor  selection  TeST).  Their  source 
code  can  be  found  in  directory  DP3 :  1301, lj . 

All  of  the  routines  developed  were  originally  part 
of  the  01LIB2  module  of  the  Chromatics  driver.  A  copy  of  the 
original  software  is  available  in  directory  DP3:[5,3].  After 
modifying  the  names  to  conform  with  the  selection  of  #4  as 
the  identifier  for  the  new  device  driver  each  subroutine  was 
removed  from  the  module  and  treated  as  a  separate  entity. 
This  was  done  for  ease  of  editing  and  troubleshooting.  To 
support  this  process  command  files  were  created  to 
facilitate  repetitive  compilation  and  tasic  building 
operations.  The  files  COMP.CMD  and  TC0MP.CMD  in  directory 
DP3:  [301,1]  cause  the  compilation  of  all  the  driver  software 
and  all  the  test  software,  respectively.  File  DUM.CMD  builds 
the  test  tasfe  DUMTST.TSK,  by  linking  the  modified 
subroutines,  the  BLOCK  DATA  programs  and  the  test  routines. 

Among  tne  test  routines  some  snort  pieces  of  code 
Have  been  included  to  accomodate  testing.  The  important  ones 
are  RMINIT,  which  inserts  the  color  table  into  the  Ramteic 
refresh  memory,  and  3ISTXT,  which  causes  text  output  to  be 
printed  in  a  larger  than  normal  format  for  viewing  ease. 
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APPENDIX  C.   PROGRAMMING  WITH  VGM 

Graphics  programming  using  VGM  is  actually  a  highly 
specialized  use  of  FORTRAN.  Because  of  tnis,  all  tne  rules 
of  PDP-11  FORTRAN  apply  as  well  as  those  of  tne  grapnics 
system,  When  using  VGM  tne  programmer  venerates  a  main 
program  wnich  references   a  Horary  of  graphics  subroutines. 

A.   SETUP 

VGM  is  initialized  by  tnree  essential  statements.  First 

CALL  INIT 
(INITialize) 

starts   tne  VGM  session.   It  sets  tne  variables  required   by 

botn   tne  operating  system  and  VGM  itself.   Tne   routine 

ensures   that   each  time  VGM  is  invoiced   it  is  in   the   same 

starting  state.  Immediately  following  this, 

CALL  INISTR(n) 
(INItialize  STReam) 

activates   tne   device  dependent  driver  software  for  stream 

'n'.  It  sets  device  parameters  and  uses  the  operating  system 

process   handling  capabilities  to  allow  application   program 

access   to  tne  particular  device  or  devices  on   tne   stream. 

Lastly, 

CALL  SELSTR  (nl  ) 
(SELect  STReam) 

directs  all  graphics  output  to  stream  'nl'.   If  another  CALL 
SELSTR    (n2)   instruction   is   encountered   before   a   CALL 
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DELSTR(nl)  instruction,  tne  grapnics  output  will  go  to  botn 
streams  nl  and  n2.  It  is  mandatory  that  each  stream  be 
prepared  by  a  CALL  INISTR(n)  before  it  is  selected  by  a  CALL 
SELSTR  (n). 

B.   ENVIRONMENT  SPECIFICATION 
1.   The  Coordinate  System 

In  VGM,  tne  user  defines  nis  graphical  world  in 
arbitrarily  selected  "world  coordinates".  Tnese  coordinates 
are  tne  medium  through  wnicn  ne  communicates  positional  data 
to  tne  system.  VGM  processes  tnose  world  coordinates  tnrougn 
a  series  of  viewing  transformations  and  eventually  derives 
"normalized  device  coordinates"  (NDC).  Tne  NDC's  are  real 
values   ranging  from   0.0  to  1.0  and  are  mapped   onto   tne 

physical  device  selected  for  viewing.   A  picture  in  NDC   is 

independent  of  any  particular  grapnics  device. 

For  VGM  to  properly  execute  tne  string  of   required 

coordinate  transformations,  tne  Normalized  Device  Coordinate 

System  must  be  specified  before  World  Coordinates.  With 

CALL  NDCSPC  (nstrm,  widtn,  neignt) 
(Normalized  Device  Coordinate  Specification) 

a   rectangular  portion  of  tne  view  surfaces  of  terminals   on 

stream    'nstrm'  is  defined.   'Width'  and  'height'  are   real 

numbers  ranging  from  0.0  to  1.0.   Tney  indicate  tne  relative 

part   of   that  dimension  of  the  view  surface  that  is   to   he 

used.   One  or  tne  otner  must  be  1.0.   Tnerefore,  eitner  tne 

full   screen  width  or  the  full  screen  height  will   be   used. 
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The  remaining  dimension  will  be  proportionately  adjusted.   A 
statement  such  as 

CALL  NDCSPC  (1,1.0, .75) 
will  set  up  tne  devices  on  stream  #1  so  that  a  viewing  area 
usins  the  full  width  of  the  screen  is  made  available.  The 
height  will  be  3/4  as  large  as  the  width  if  that  much  is 
available.  If  a  dimension  specification  is  too  lar?e,  the 
maximum  available  is  used.  The  NDCSPC  command  normally  is 
used  only  once  for  each  stream. 
2.  The  View  Surface 

After   setting   the   total  viewing  area  available, 
"viewports"  are  assigned  to  the  streams  by 

CALL  VIEW  (nstrm,  xmin,  ymin,  xmax,  ymax) 
A  viewport  is  a  portion  of  the  available  surface  (NDC  space) 
that  will  be  used,  up  to,  but  not  exceeding,  tne  total 
declared  surface.  'Xmin',  'ymin',  'xmax',  and  'ymax'  are  NDC 
values  and  must  be  within  the  bounds  specified  in  the  NDCSPC 
call.  A  viewport  declaration  stays  in  effect  until  a  new  one 
is  declared.  The  viewport  may  be  changed  as  often  as  tne 
user  desires  in  the  main  program. 

The   "window"  is  the  counterpart  of  the  viewport   in 
the  world  coordinate  system  and  is  set  by 

CALL  WINDOW  (nstrm,  xmin,  ymin,  xmax,  ymax) 
The   parameter  values  except   for   'nstrm'   are   in   World 
Coordinates  and  are  arbitrarily  selected  by  the  user  to  meet 
his   requirements   for  clipping  and   imaee   transformations. 
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This   is  the  part  of  World  Coordinates  that  the   picture   is 
created   in.   The  window  is  the  wort  area  of  the  programmer. 
For  display,   tbe   clipped   and  transformed  images   in   the 
window  are  mapped  to  the  NDC  space  defined  by  the  viewport. 
3.   Background  Color 

On   color   capable   devices   the   last   environment 
setting  operation  is  to  define  the  background  with 

CALL  BCKCOL(ival) 
(BaCKground  COLor) 

to  set  the  attribute  and 

CALL  ERASE 

to  bring  it  up  on  the  screen. 

Tne   current  version  of  VGM  allows  selection  of   one 

of   only  eight   colors   available.   Selection   is  done   by 

specifying  an  integer  value  between  2   and  7  for  'ival'.   The 

default  color  table  contains  blaci,   blue,  green,  cyan,  red, 

magenta,  yellow,  and  rfnite,  in  tnat  order. 

C.   CREATING  A  PICTURE 

With   the  devices  initialized,   and  the  environment  set, 

tbe  next  step  is  to  open  a  segment.   To  do  this  the  type   of 

the  intended  segment  must  first  be  declared  by 

CALL  SEGTYP  (itype) 
(SEGment  TTPe). 

An   'itype'  value  of   1  indicates   tnat   all   subsequently 

created   segments  will  be  non-retained.   A  value  of  2   means 

tnat  they  will  be  retained. 
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After  tne  type  nas  been  establisned,   tne  segment   Is 

opened  with 

CALL  CRESEG  (nse*mt) 
(CREate  SEGment). 

'Nsegmt'  is  an  integer  value  that  uniquely  identifies   tne 

particular  segment.   Once  tne  segment  is  open,   tne  user 

creates  his   image   by  invoicing  primitives  and  assigning1 

attributes.   Any  primitive  attribute  values  declared  Before 

closing  the  segment  are   static.   Declaration  of  segment 

attributes  is  not  allowed  while  a  segment  is  open.   As  eacn 

primitive  is  executed  its  contribution  to  the  total   image 

will  be  displayed.   When  the  particular  image  is  completed, 

the 

CALL  CLOSEG 
(CLOse  SEGment) 

instruction  is  issued.   It  is  not  necessary  to   specifically 

identify  tne  segment  being  closed,  since  only  one  is  allowed 

to  be  open  at  any  given  time. 

After  closing  a  segment,  a  number  of  options  are  open  to 
the  user.  He  may  terminate  the  session  by  normal  FORTRAN 
procedures  or  ne  may  continue  on  and  manipulate  devices, 
streams  and  segments,  fie  may  alter  dynamic  attributes  and 
create  additional  segments  subject  to  tne  limitations  of  VGM 
and  FORTRAN. 
D.   EXECUTING  THE  PROGRAM 

After  creating  the  source  code  for  a  VGM  program  it 
should   be  independently  compiled   into  an  object   file. 
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Incorporating  the  user  file  and  the  VGM  library  into  an 
executable  taslr  requires  tne  following  command  sequence  to 
be  issued  to  the  RSI  Taslc  Builder  (for  purposes  of  the 
example,  MAIN  is  selected  to  be  tne  name  of  the  user's 
program) : 

TKB>   MAIN/CP/FP,VGM/-S?=VGMLT/MP 

ASG  =  ST:  1 

ASG  =  ST:  Z 

ASG  =  ST:  4 

ASG  ■  TI:  5 

ACTFIL  =  3 

MAXBUF  =  80 

FMTBUF  =  80 

// 

Before  executing  the  tasit  (now  stored  in  file  MAIN.TSK)  it 
is  necessary  to  INSTALL  the  device  drivers.  For  each  stream 
that  will  be  used  by  MAIN.TSK.  The  MCR  command  to  RSX  is 

>INS  OnDRIV 
where   'n'   is   the  integer  identifier   for   the   particular 
driver.  Tne  command 

>R0N  MAIN 
will  execute  the  user's  graphics  program. 
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